[Openid-specs-ab] Nonce value suggestion for the Implicit Flow
George Fletcher
gffletch at aol.com
Thu Nov 14 15:21:04 UTC 2013
Hi Justin,
From a general solution perspective, how is this different from from
the last sentence that Mike wrote
"A related method applicable to JavaScript Clients is to store the
random value in HTML5 local storage and use a cryptographic hash of
this value."
Basically, native applications (or desktop apps) can all store something
local like the JavaScript client Mike mentions. Would it help to just
make this last sentence a little more generic?
A related method for JavaScript Client, native applications or rich
desktop applications is to store the random value in local storage
and use a cryptographic hash of this value as the nonce the request.
Thanks,
George
On 11/13/13 7:26 PM, Richer, Justin P. wrote:
> I like the text that's there, but let's add this to cover the other
> (in my view, more common) case:
>
> "Another option, often useful for clients that are web servers or
> native applications, is to store the value of the nonce in a protected
> store local to the client, away from the user agent. This value can be
> retrieved from the store when the end user returns to the client via
> the redirect_uri and used when validating the id_token."
>
> -- Justin
>
> On Nov 13, 2013, at 10:16 PM, Mike Jones <Michael.Jones at microsoft.com
> <mailto:Michael.Jones at microsoft.com>> wrote:
>
>> If you want to propose specific text changes, we can look at them.
>> Otherwise, I think we're good.
>> -- Mike
>> *From:*John Bradley [mailto:ve7jtb at ve7jtb.com <http://ve7jtb.com>]
>> *Sent:*Wednesday, November 13, 2013 12:40 PM
>> *To:*Brian Campbell
>> *Cc:*George Fletcher; Mike Jones; openid-specs-ab at lists.openid.net
>> <mailto:openid-specs-ab at lists.openid.net>
>> *Subject:*Re: [Openid-specs-ab] Nonce value suggestion for the
>> Implicit Flow
>> That looks good.
>> One question is if we want to also say the nonce value may be stored
>> as part of the session state on the client (webserver).
>> Adding too many options may just confuse people though.
>> John B.
>> On Nov 13, 2013, at 11:38 AM, Brian Campbell
>> <bcampbell at pingidentity.com <mailto:bcampbell at pingidentity.com>> wrote:
>>
>>
>> "a random value as an HttpOnly a session cookie" -> remove the "a"
>> after HttpOnly?
>>
>> On Wed, Nov 13, 2013 at 11:35 AM, George Fletcher <gffletch at aol.com
>> <mailto:gffletch at aol.com>> wrote:
>>
>> I'll let John quibble over the specifics :) ... but it looks good to
>> me. Thanks, George
>>
>> On 11/13/13 1:30 PM, Mike Jones wrote:
>>
>> Please review the new text
>> athttp://openid.bitbucket.org/openid-connect-core-1_0.html#NonceNotes,
>> which is where the implementation suggestions for the nonce
>> parameter have been moved.
>> -- Mike
>> *From:*openid-specs-ab-bounces at lists.openid.net
>> <mailto:openid-specs-ab-bounces at lists.openid.net>[mailto:openid-specs-ab-bounces at lists.openid.net]*On
>> Behalf Of*Brian Campbell
>> *Sent:*Wednesday, October 30, 2013 9:00 AM
>> *To:*John Bradley
>> *Cc:*openid-specs-ab at lists.openid.net
>> <mailto:openid-specs-ab at lists.openid.net>
>> *Subject:*Re: [Openid-specs-ab] Nonce value suggestion for the
>> Implicit Flow
>> 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
>> <mailto: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 <mailto: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>[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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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
>> <http://mitre.org/>]
>> *Sent:* Thursday, October 24, 2013 12:56 PM
>> *To:* Mike Jones
>> *Cc:* openid-specs-ab at lists.openid.net
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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
--
George Fletcher <http://connect.me/gffletch>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131114/dcdd2c5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XeC
Type: image/png
Size: 80878 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131114/dcdd2c5f/attachment.png>
More information about the Openid-specs-ab
mailing list