[Openid-specs-ab] Proposal for adding hash to id_token

John Bradley ve7jtb at ve7jtb.com
Thu Jan 12 02:06:28 UTC 2012

That is the reason we have been resisting requests to add other claims about the user to the id_token.

It currently only contains the user_id claim and info about the authentication event like authentication context.

In the full profile the RP has the ability to as for the id_token encrypted.  

If leaking the cookie is a concern the best thing is to get a encrypted id_token.

Until we see the session management spec, I am uncertain what effect encrypted id_tokens will have on that.  It may be that they will need to be encrypted to multiple recipients.

John B.
On 2012-01-11, at 10:24 PM, hideki nara wrote:

> Thank you John.
> I'd like to mention that privacy data should not
> be include in id_token because  id_token can be in cookie as well.
> regards
> ---
> hideki
> 2012/1/12 John Bradley <ve7jtb at ve7jtb.com>:
>> Yes We can add something about not storing long lived access tokens as cookies.
>> I think there is already some language about that in OAuth security considerations.
>> I understand it is tempting to put the access token in the id_token.
>> We have looked at that several times.
>> However keeping them separate allows the id_token to be set as a cookie without introducing additional security problems.
>> John B.
>> On 2012-01-11, at 9:21 PM, hideki nara wrote:
>>> Thank you very much, Breno
>>> Some security or privacy considerations in Messages or Session Management
>>> should include descriptions about #2.
>>> ---
>>> hideki
>>> 2012/1/12 Breno de Medeiros <breno at google.com>:
>>>> Two reasons.
>>>> 1. The hash has known length while tokens can be large. Since the idtoken is
>>>> often used for different purpose, it doesn't need to be always paired with
>>>> the access token.
>>>> 2. The idtoken can readily be used as a cookie as it supports static
>>>> validation. But using access token as cookie is not a good practice
>>>> securitywise.
>>>> On Jan 11, 2012 12:07 AM, "hideki nara" <hdknr at ic-tact.co.jp> wrote:
>>>>> Hi, Breno
>>>>> How about simply putting everything in the id_token when id_token is
>>>>> responded ?
>>>>> regards
>>>>> ---
>>>>> hdknr
>>>>> 2012/1/10 Breno de Medeiros <breno at google.com>:
>>>>>> The proposal is that, when id_token issued in combination with code
>>>>>> and/or access token, it includes a hash of those values.
>>>>>> Rationale: An authentication protocol implements a security service.
>>>>>> That means it must provide all the security semantics reasonably
>>>>>> expected by clients. If clients receive multiple tokens as the result
>>>>>> of an authorization flow, it's reasonable for the client to assume
>>>>>> that they all belong to the same user. If the id_token does not
>>>>>> include a hash it implies that an additional RPC must be part of the
>>>>>> authentication protocol necessarily (we can't make assumptions about
>>>>>> how the client will use the tokens later, the security semantics
>>>>>> should be correct regardless). That's much more expensive than a hash
>>>>>> check.
>>>>>> Proposed mechanism:
>>>>>> - When an id_token is issued in combination with a code or access_token
>>>>>> -- The code_hash and/or the access_token_hash are computed using the
>>>>>> _same_ hash algorithm specified by the id_token Signature Algorithm.
>>>>>> E.g., if RSA-SHA-256 is the signature algorithm for the id_token, then
>>>>>> SHA-256 is the hashing algorithm for the the token hashes.
>>>>>> -- The hash output is truncated in half by discarding the half
>>>>>> rightmost bits (in accordance with
>>>>>> http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf,
>>>>>> section 5.1).
>>>>>> -- The hash output is Base64 Url encoded and added to the id_token JSON
>>>>>> payload.
>>>>>> e.g:
>>>>>> id_token's JWT payload: { ...., "access_token_hash" :
>>>>>> "abcdefghi_012A-BCDEFGHI", "code_hash": "zwxy_987-ZWXY", ...} (we may
>>>>>> want to define shorter names for these JWT fields)
>>>>>> --
>>>>>> --Breno
>>>>>> _______________________________________________
>>>>>> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120111/780e5b6b/attachment.p7s>

More information about the Openid-specs-ab mailing list