[OAuth] Native Client code leakage

[John Bradley]

On iOS and other platforms tokens are returned from the browser to apps via a custom scheme URI.

On iOS atleast any app can register any scheme, and it is non deterministic what app gets called if multiple apps register the same scheme.

This leads to the possibility of codes being leaked to the wrong app.

A way around this proposed by both Ping and Google is to have the app generate a unique id for the request that is passed to the AS, and is then used as the value of the password in http basic authentication to the token endpoint.

Currently Connect has request identifier (Similar to saml:ID) called "nonce". That could be used as the value or we could add a new parameter. This would not work with "nonce" if the id_token is returned in the front channel , but that would be a bad idea anyway if we are concerned about interception.

If we reuse nonce then mostly we need a way for the client to know that the AS supports this, as it needs to know what the AS will be expecting as a password.

[Torsten Lodderstedt]

I assume the attack would not work, if the client would be confidential? Why not use dynamic registration (provisioning of a client instance specific secret) to prevent this attack? This would also work for vanilla OAuth clients.

[Brian Campbell]

This applies to OAuth in general and not just Connect. As such, it should probably be addressed as some kind of simple extension to the OAuth code response and grant type.

I'd strongly prefer not to overload password and client authentication to do it as that is not a very cohesive approach and mixes protocol level messaging with entity authentication. Rather I'd like to see a new parameter (message_id or request_id or something) to make and check the association. If the parameter is sent in the authorization request, then it must be sent with the same value on the associated code grant type request to the token endpoint.

[Nat Sakimura]

Here is the link to the proposed draft based on Sunday discussion.

http://bit.ly/1chmIeG

[John Bradley]

It is better to make this a proof of possession mechanism for code. There may be multiple instances of software with the same client_id the verification needs to be performed at the same layer that is validating code so it has access to the proof material. The http basic authentication layer should not need to know about code and how to validate it.

[Nat Sakimura]

Just recording what was agreed upon by the authors back in Sept. 26.

Re: tcse to be sent:

1. Default: Just a random number.
2. Iff the server supports and the client has done a alg negotiation/registration with the server, client may send hash etc. instead. In this case, the alg needs to be adhered.

I will apply the fix to the next rev of http://bit.ly/1chmIeG

BTW, since this is now the OAuth issue, shall we close this ticket or at least mark it clearly that we are not touching it in the OpenID Connect specs?

[Michael Jones]

We will write an Implementer's Note describing the problem and saying that this issue is being worked on in the IETF and that implementations may want to solve it in the manner adopted by the IETF.

[Michael Jones]

Fixed #864 - Described Native application code leakage problem on iOS

→ <<cset fb190e1ba293>>