[Openid-specs-ab] Lite Draft 9
Breno de Medeiros
breno at google.com
Thu Aug 25 17:57:39 UTC 2011
Tentative answers to questions inline.
On Thu, Aug 25, 2011 at 09:02, John Bradley <ve7jtb at ve7jtb.com> wrote:
> This is a new requirement that has just surfaced based on Google's security analysis.
> So I may not be the best person to present their argument.
> Facebook is currently doing something like this with there signed request tokens where they are including code in the token, or a hash of the access token.
> Facebook's implementation is not completely based on OAuth 2 draft 10. It is a bit hard to figure it out from the documentation.
> It is true that there will be multiple id_tokens per access token as they are refreshed.
> What I think both Google and Facebook are trying to prevent is a cut and paste attack where using the implicit flow you could swap the access token with one gatherd in some other way. This would allow a user to spoof attributes from someone else. Clearly something we want to avoid. If the RP is not following the spec and taking the identity from the user-info endpoint, then the entire identity can be spoofed.
> Because of a lack of information at the user-info endpoint about audience and other session information like nonce, the implicit flow without a id_token is fraught with holes for SSO.
> So rather than dumping the implicit/token flow Google's proposal is that whenever the IdP issues a access token and id_token together, they include in the id_token a short hash of the access token so that when a client receives the pair they can tell if the access token is the one issued with the id_token.
> I think there are a number of open questions for the call today:
> 1. If a id_token is refreshed will it still carry the optional hash. (Probably No)
That would make it hard to validate. It's only necessary to have hash
when two tokens are issued simultaneously.
> 2. In the code flow where both tokens come from the token endpoint directly over TLS is this necessary? (Probably not, but might not hurt for consistency)
It should be done, both for consistency and because since both
access_token and id_token are bearer tokens, one can't assume that
only the immediate caller at the token endpoint needs to validate the
binding between the tokens. Some web environments include layers of
delegation to shared infrastructure.
> 3. In the code+id_token flow should the hash of code be included, code itself, or should the RP just compare the two id_tokens and throw an error if they are different?
I favor consistency in this case.
> This needs more discussion and documentation before it is added.
> John B.
> On 2011-08-25, at 3:03 AM, Andreas Åkre Solberg wrote:
>> On 24. aug. 2011, at 19:56, John Bradley wrote:
>>> Google has however added a bit of a twist on the last call.
>>> They are proposing that a hash of the access token be included in the id_token.
>>> The idea is that that allows a RP to know if the received access token relates to the id_token.
>> Sorry, but I feel completely lost here.
>> An id_token is kind of a handle to the current user session (at the provider), right?
>> And the access token is kind of credentials to get user information about the authenticated user, right?
>> There may be many id_token-s (for the same 'session' at the RP), derived from the same session at the provider; by the use of the 'Refresh Session' service.
>> And the consumer may request more than one access token for the same user, by using the OAuth refresh_token.
>> If both the access token and id_token is refreshed, which of the access token should then the new id_token refer to ?
>> The way I've understood it, an id_token can be related to a session at the provider, and the access_token is not associated with any session directly, but could potentially be tracked back to the session where it was issued.
>> Like this: http://clippings.erlang.no/ZZ56D6DED4.jpg
>> I'm tempted to suggest that the id_token included a session identifier. Then two id_tokens could be more easily reckgonized to represent the same session. The User Info Service could then potentially return a reference to the session (via the session identifier) where the access token was issued.
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab