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

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
> <sberyozkin@gmail.com> 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
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>