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

hideki nara hdknr at ic-tact.co.jp
Thu Jan 12 01:24:08 UTC 2012


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
>


More information about the Openid-specs-ab mailing list