1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Nonce requirement in hybrid auth request

Issue #972 resolved
Vladimir Dzhuvinov created an issue

I noticed that Core doesn't specify the conditions when nonce is required in hybrid authentication requests:

http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest

Shouldn't there be a sentence that nonce is required when response_type is "code id_token" or "code id_token token" (and optional with "code token")?

The hybrid example seems correct.

Cheers,

Vladimir

Comments (19)

  1. Michael Jones

    code+token response type doesn't actually require use of a nonce since no ID Token is returned on the front channel.

    John - But the nonce doesn't hurt. We should leave this as-is. Mike - Changing it at this point would cause an interop issue.

    John will close this one as won't fix

  2. John Bradley

    In the spec it is clear that nonce is optional for "code" and required for "token id_token" and "id_token"

    I need to look at it some more but it seems that "code id_token", "code id_token token" and "code token" could be interpreted as not requiring nonce.

    The intent was for it to be required if the id_token is returned from the Authorization endpoint.

    At this point to avoid breaking backwards compatibility we could make all of these a SHOULD send nonce.

    I think we lost a sentence someplace on one of the refactoring

  3. Michael Jones

    This statement in http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken makes it clear that nonce is required for all Hybrid response types:

    Use of the nonce Claim is REQUIRED for this flow.

    However, what is missing from 3.3.2.1 (Hybrid Authentication Request) is this language which I will copy from 3.2.2.1 (Implicit Authentication Request):

    nonce

    REQUIRED. String value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. For implementation notes, see Section 15.5.2.

    That doesn't change the meaning of the spec, but makes it much more explicit.

  5. John Bradley

    OK, Having nonce required in the id_token but not explicitly required in the request, would not be noticed by many developers. This wording is better, and isn't a normative change.

  6. Brian Campbell
    • changed status to open
    • edited description

    Reopening this one as a result of significant discussion in and around #1052 that brought to light an erroneous conclusion having been reached here previously. Rather, as @vdzhuvinov initially suggested, there should 'be a sentence that nonce is required when response_type is "code id_token" or "code id_token token" (and optional with "code token")'.

  7. Brian Campbell

    Pull request #4 updates the nonce text added to the hybrid section by 58ba615e7f43 with text to clarify that in hybrid authn requests nonce is required when response_type is code id_token or code id_token token and optional with code token

  10. Michael Jones

    clarify that in hybrid authn requests nonce is required when response_type is "code id_token" or "code id_token token" and optional with "code token" - resolving Issue #972 and related to issue #1052

    → <<cset bfcd8b0dd48a>>

  11. Michael Jones

    Merged in b_c/forking-connect/i972 (pull request #4)

    clarify that in hybrid authn requests nonce is required when response_type is "code id_token" or "code id_token token" and optional with "code token" - resolving Issue #972 and related to issue #1052

    → <<cset e6d511b2e7bc>>

  14. Michael Jones

    I did consider it. Given the structure of the description of Hybrid, in which Section 3.3.2 and its subsections define the interactions with the authorization endpoint and Section 3.3.3 and its subsections define the interactions with the token endpoint, keeping the phrase "returned from the Authorization Endpoint" in 3.3.2.11 is correct.

    Rather than changing that context-setting text, which is correct in that context, I changed the description of the "nonce" claim to explicitly state that it's required when the "nonce" request parameter is used.

  16. Michael Jones

    It used to say that the nonce claim is required for the flow. Now it says that a nonce claim is required when requested. The latter is much clearer.

    Couple that with the new text that Brian wrote at https://openid.bitbucket.io/connect/openid-connect-core-1_0.html#HybridAuthRequest which says when a nonce must be requested for Hybrid interactions - required for "code id_token code" and "code id_token token" and optional for "code token", and you have a complete an unambiguous description.

    FYI, Brian's new text says:

    nonce REQUIRED if the Response Type of the request is code id_token or code id_token token and OPTIONAL when the Response Type of the request is code token. It is a string value used to associate a Client session with an ID Token, and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. For implementation notes, see Section 15.5.2.

  18. Michael Jones

    Call me on Skype please. There's some misunderstanding and I'd like to figure out what it is before going back and forth in issue comments anymore. Thanks.

  19. Hans Zandbelt

    After our call I agree: I missed the fact that the organization structure of the spec already puts the text of 3.3.2.11 https://openid.bitbucket.io/connect/openid-connect-core-1_0.html#HybridIDToken in the context of tokens returned from the authorization endpoint (not just by the last part of that intro sentence).

    And then 3.3.3.6 https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken2 (one could argue that the HTML fragment anchors could be more explicit about the context) completes that with text about tokens returned from the token endpoint, which then only very implicitly dictates nonce behavior, but I'll stop here because it is technically all correct now.

  20. Log in to comment
Assignee
Type
bug
Priority
minor
Status
resolved
Component
Core
Milestone
Errata
Version
–
Votes
0
Watchers
0
Jira: the preferred issue tracker for Bitbucket. Join the team!