[Openid-specs-ab] Nonce value suggestion for the Implicit Flow
Richer, Justin P.
jricher at mitre.org
Thu Nov 14 00:26:38 UTC 2013
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 at http://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131114/98754e16/attachment.html>
More information about the Openid-specs-ab
mailing list