Messages, Multi Token Response, add hash of token to id_token

[John Bradley]

In order to prevent user agents from modifying Authorization responses we need to bind the response to the session with a more secure method than exists in OAuth 2.0 itself. OAuth 2.0 provides the client no protection from the user or user-agent modifying responses in the implicit flow.

Proposal: Modify multi-token response:

'id_token code' The response is fragment encoded code is passed as a claim in the id_token, and not as a separate parameter.

'id_token code token' The response is fragment encoded code is passed as a claim in the id_token, and not as a separate parameter, token is passed as a separate parameter.

In Messages add a new claim to id_token.

aft (Access Token Fingerprint) OPTIONAL This paramater is required for id_tokens issued by the Authorization endpoint when issued in conjunction with a access_token. The value is the calculated by using the SHA hash of the equivalent bit length to the one used in the signing algorithm. If "lag":="HS256" then a SHA256 hash is calculated over the access_token. The hash output is then truncated in half by discarding the 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 base64url encoded and used as the fingerprint value in the "aft" claim.

The check_id endpoint needs to take access_token as a paramater (I am thinking making this endpoint POST only). It would return an error if the access token failed to validate.

There may be a simplicity argument for not truncating the hash.

[Michael Jones]

This seems like it would break the proposed encoding in the current Multiple Response Types document by returining the code as a claim in the ID token rather than as a separate parameter. Are we really OK with this breaking change? Also, how does this related to what Facebook actually does? (Not that we have to do the same thing, but it would be good to understand how this proposal relates to their deployment.)

[Nat Sakimura]

So, in today's WG Call, John explained that it was what FB was doing, and would probably be simpler for developers.

I checked with Tatsuya, who is building solutions for our customer and he said it indeed would be simpler, so that is a good news.

My concern is semantics.

As I understand, scope is something that request what is to be returned overall, and response_type is a parameter that request what is to be returned from the Authorization endpoint response parameters.

So, if response_type=code, code is returned from the Authz EP, and if response_type=token, token is retunred from the Authz EP. Expanding on this semantics, response_type=code id_token would mean that code and id_token has to be returned from Authz EP as independent parameters. If code is to be returned as part of the id_token, I feel that it should be just id_token, or a new response type such as code_in_id_token.

We can then through away a response_type "code id_token".

For "code token id_token", it would be replaced with "code_in_id_token token". This is going to reduce the number of permutation.

[hideki nara]

I like "url?jwt( all parameters )" or "url#jwt( all parameters )" , but breaks OAuth.... Please forget.

[Michael Jones]

Duplicate of #510.