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 <sberyoz...@gmail.com> 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 >> <sberyoz...@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 >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
