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

Breno de Medeiros breno at google.com
Tue Jan 10 00:59:07 UTC 2012

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