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

hideki nara hdknr at ic-tact.co.jp
Thu Jan 12 00:21:30 UTC 2012


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


More information about the Openid-specs-ab mailing list