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

Brian Campbell bcampbell at pingidentity.com
Wed Oct 30 15:59:57 UTC 2013


The nonce is a different approach to protecting against things like replay
prevention but doesn't have the same scaling implications as tracking token
ids. Which is nice.


On Wed, Oct 30, 2013 at 4:13 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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<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 <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@ <jricher@>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 at
> http://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> <http://connect.me/gffletch>****
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/d14bb832/attachment-0001.html>


More information about the Openid-specs-ab mailing list