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

John Bradley ve7jtb at ve7jtb.com
Thu Jan 12 00:57:32 UTC 2012

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/95103e35/attachment.p7s>

More information about the Openid-specs-ab mailing list