Re: [OAUTH-WG] Wrapping access token and codes

[John Bradley <[e-mail]>]

You don't need to use JWT access tokens, you could use a opaque token and introspect it.  However JWT access tokens are likely the simplest answer for getting the clients proof key to the RS.

in http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution you can register a secret for the client and encrypt a symmetric key to it, if you want to use symmetric proofs for the RS.

For performance using symmetric proofs to the RS is not a bad option.   

If the client is a server and has appropriate hardware protection for asymmetric keys then using a asymmetric key protected by a HSM is going to be the most secure.

For native public client, they can start the flow with SPOP and when they exchange code and the code verifier get a symmetric proof key for the AT.  

SPOP and Proof of possession for AT are complimentary and used to protect different parts of the flow.

The c_hash and at_hash that we added to the id_token in Connect allow a client to determine if a token delivered in the front channel has been tampered with by the user agent.
(Some AS return at_hash in id_tokens returned from the token endpoint for interoperability, but hat is not required)  

John B


On Nov 7, 2014, at 8:12 AM, Sergey Beryozkin <[e-mail]> wrote:

> Hi
> On 06/11/14 18:51, Bill Mills wrote:
>> So you're wanting end to end security not relying on TLS?
>> 
> I was not really thinking about HTTPS vs HTTP in this case. I'm kind of in the process of appreciating what JWE/JWS can do and I can't help trying to consider it applying at the every possible opportunity :-)
>> 
>> Have you seen the new draft on protecting codes from interception?
>>  Currently called SPOP but needs a different name.
>> 
> Do you mean this one:
> http://tools.ietf.org/html/draft-ietf-oauth-spop-02
> ?
> 
> Yes I did - it's a different mechanism though, I guess it is of most help to the pubic clients, though we do not distinguish in our code, a confidential client can use the SPOP mechanism too.
> 
> I think the wrapping idea is probably what
> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-01#ref-10
> 
> talks about with respect to distributing a key using a JWE option.
> That actually looks interesting; I haven't analyzed it much yet but apparently it is tied to the access token being necessarily in a JWT format, may be I did not get it right yet.
> 
> I guess it just can be interesting even in the TLS case. I believe people do not mind doing the extra protection even in the TLS cases.
> 
> Or take the implicit grant; if the wrapped access token reaches a client which is aware of WebCrypto API then it is probably making this grant much more secure...
> 
> Sergey
> 
>> On Thursday, November 6, 2014 4:12 AM, Sergey Beryozkin
>> <[e-mail]> wrote:
>> 
>> 
>> Hi
>> 
>> Does it make sense to consider supporting an access token or code
>> wrapping as part of the standard OAuth2 responses ?
>> 
>> For example, if a client has registered its public key with AS then say
>> the access token response would contain the regular
>> 
>> {"access_token":"1234345"}
>> 
>> except that "1234345" would actually be a JWE RSA-OAEP wrapped opaque
>> token with a client's public key being used. Or a direct key encrypted
>> token if the client and the server only share the client secret
>> allocated to the client during the registration.
>> 
>> The net result is that only the registered confidential client would be
>> able to extract the actual opaque access token. The response would
>> actually be
>> 
>> {"access_token":"1234345", wrapped:true}.
>> 
>> I definitely plan to use this approach as a simple mechanism for making
>> a safer distribution of mac keys as part of access token responses; but
>> IMHO it can be handy for minimizing the possibility of the
>> access/refresh tokens or codes being intercepted...
>> 
>> Sergey
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth