[Openid-specs-ab] Nonce value suggestion for the Implicit Flow

John Bradley ve7jtb at ve7jtb.com
Wed Oct 30 10:13:54 UTC 2013


The nonce is opaque to the AS, it is sent by the client and validated by the client.   It binds the signed id_token to something in the user's browser session.   This is critical to prevent attacks on the implicit flow, where the redirect_uri is not sent to the token endpoint for validation.  It is not required for the "code" flow.  In the hybrid flows  it needs to be used to validate the id_token presented in the front channel as well, as  the client may be using the id_token before exchanging code at the token endpoint, and discovering an attack.

I think it also prevents some attacks against code interception that checking the redirect_uri wouldn't so in a high loa deployment I would check both nonce and the redirect_uri.

Are you asking about "jti" in the assertion used to authenticate the client to the token endpoint?

On Oct 30, 2013, at 1:44 AM, Anthony Nadalin <tonynad at microsoft.com> wrote:

> I’m not seeing how you are dealing with duplicate nonces as this can be a scaling issue when dealing with millions of requests, the nonces need better advice
>  
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Tuesday, October 29, 2013 7:33 PM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Nonce value suggestion for the Implicit Flow
>  
> You want to store the random value and send the hash.   Saving the hash is not secure unless it is signed. 
>  
> The idea is to force an attacker to compute a plaintext for the hash (hard to impossible depending on length) in order to be able to present the response from the AS.
>  
> For case 1:  The Client can generate a random value with sufficient entropy and store that value in local storage.  This value is then hashed to produce a nonce value. The hashed value  could optionally be truncated to a sufficient number of bits (such as 128) before use. 
> On Oct 29, 2013, at 9:40 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 
> Here’s an attempt at simplifying George’s text.
> For case 1:  The Client can generate a random value with sufficient entropy and store a cryptographic hash (such as SHA-256) of that value in local storage.  The hashed value could optionally be truncated to a sufficient number of bits (such as 128) before use.  The stored value is used as the nonce value.
> For case 2:  The Client can generate a random value with sufficient entropy and store that value as an HttpOnly session cookie.  A cryptographic hash (such as SHA-256) of the cookie value (or a truncation of the hash value to a sufficient number of bits) is used as the nonce value.
>  
> Am I correct that the cryptographic hash function is used to spread the entropy present in the random value generated throughout the nonce value in both cases?
>  
> Comments?
>  
>                                                                 -- Mike
>  
> From: Richer, Justin P. [mailto:jricher at mitre.org] 
> Sent: Saturday, October 26, 2013 11:33 AM
> To: George Fletcher
> Cc: John Bradley; Mike Jones; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Nonce value suggestion for the Implicit Flow
>  
> I don't know where the best place is to provide this guidance. If we have a "validating the ID Token" sub-section in the new ID Token section, then maybe it would best fit there.
>  
> +1 to this idea with a cross link from the nonce definition.
>  
>  -- Justin
>  
>  
> On Oct 25, 2013, at 6:17 AM, George Fletcher <gffletch at aol.com> wrote:
> 
> 
> 
> If we are going to give guidance, then we really need to give guidance for two different use cases...
> 
> 1. The "client" will validate the response locally in the browser
> 2. The "client" will validate the response at it's server (even though it's using the implicit flow)
> 
> For use case 1: One method to achieve this is for the client to generate a random string with sufficient entropy and store a SHA-1 hash of the string in local storage. Then use the SHA-1 hash of the random string as the value of the nonce parameter. To validate the nonce on receipt of the ID Token, extract the nonce from the ID Token and compare it to the stored SHA-1 hash in local storage.
> 
> For use case 2: One method to achieve this is for the backend server to use a SHA-1 hash of the "clients" protected session cookie as the value of the nonce parameter when constructing the AuthorizationRequest. Note that the Session cookie SHOULD be protected (restricted to SSL and not readable by JavaScript) for this method. To validate the ID Token at the server, the server calculates a SHA-1 hash of the Session cookie value and compares that to the nonce value in the ID Token.
> 
> I don't know where the best place is to provide this guidance. If we have a "validating the ID Token" sub-section in the new ID Token section, then maybe it would best fit there.
> 
> Thanks,
> George
> 
> On 10/24/13 7:16 PM, John Bradley wrote:
> We want the implicit flow to validate nonce,  it would be better to have some reasonable advice for using HTML local storage rather than session cookies.
>  
> On 2013-10-24, at 3:44 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 
> 
> We could drop it from the Implicit Flow, as it’s already present in the Code Flow.  Does that work for people?
>  
>                                                             -- Mike
>  
> From: Richer, Justin P. [mailto:jricher at mitre.org] 
> Sent: Thursday, October 24, 2013 12:56 PM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Nonce value suggestion for the Implicit Flow
>  
> I'm actually in favor of dropping this example, or else providing it in a list of alternatives. The important thing is that the client can validate the exact value of the nonce parameter on its way back through, the mechanics of how that happens are client specific (but we can provide simple guidance).
>  
>  -- Justin
>  
> On Oct 24, 2013, at 11:44 AM, Mike Jones <Michael.Jones at microsoft.com>
>  wrote:
> 
> 
> 
> 
> For the Implicit Flow, the “nonce” description contains this text athttp://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest:
> Sufficient entropy MUST be present in the nonce values used to prevent attackers from guessing values. One method to achieve this is to store a random value as a signed session cookie, and pass the value in thenonce parameter. In that case, the nonce in the returned ID Token can be compared to the signed session cookie to detect ID Token replay by third parties.
>  
> George wrote this about the suggestion in his review:
> “I'm not sure this suggestion makes sense for the implicit flow. The client would need to write a cookie value on the domain of the redirect_uri and the attempt to read it on the return of the implicit flow. Wondering if a local storage example would make more sense.”
>  
> Do people agree with him?  If so, does someone want to supply specific alternative text to use?
>  
>                                                             -- Mike
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>  
> -- 
> <XeC.png>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/afec32fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/afec32fc/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list