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

Justin Richer jricher at mitre.org
Thu Jan 12 13:49:54 UTC 2012


These requirements sound more to me like a request for a 
signed-http-message (a-la OAuth1 or the MAC token) than something else 
crammed into id-token.

  -- Justin

On 01/09/2012 07:59 PM, Breno de Medeiros wrote:
> I forgot to describe the validation semantics. Consider that
> Validate() is a boolean operation that accepts as input one or more
> tokens of various types, one of which is an id_token.
>
> Assume that a client has an id_token and access_token and calls
> Validate() in various ways:
>
> Validate(id_token) -- this will fail or succeed depending on whether
> the standard id_token signature validates, where the field
> 'access_token_hash' is taken at face value (i.e., access_token_hash
> fields are dealt with no differently than if they referred to a user
> id or other payload content).
>
> Validate(id_token, access_token) -- this will succeed if:
>   -- Validate(id_token) would succeed; and
>   -- The embedded access_token_hash value in the id_token matches the
> computed value of the access_token provided.
>
> On Mon, Jan 9, 2012 at 16:43, Breno de Medeiros<breno at google.com>  wrote:
>> 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
>
>



More information about the Openid-specs-ab mailing list