Hi John,
On 07/11/14 20:42, John Bradley wrote:
Inline
On Nov 7, 2014, at 1:02 PM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
Hi John
Many thanks for the clarifications. FYI, I posted some comments re the
http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution to a
dedicated thread.
I just wonder is it OK to distinguish between bearer and JWT tokens in the spec
texts referring to the client processing the access token responses. As far as
the access tokens are concerned JWT token is just a data container which can be
useful to AS/RS for the purpose of representing the relevant info, I'm curious
if the client needs to know anything about the access_token
format/representations at all.
The goal is for the AT to continue to be opaque to the Client as they are with
bearer tokens.
The spec contains an example of how to do it with a JWT access token, and is
the method I prefer. Introspection or a combination of introspection and
structured token can be used.
Sure, so the way I'd like to look at it is that it is an informative
content for the AS or token grant implementers, specifically, how a JWT
can be used to link to a key being distributed, etc.
Sec 3.2 states that the use of JWT AT is optional.
OK,
In some cases real time claim info from the AT is desired by the RS. The way
I would do that is to send a JWT with the key info so that session setup can be
done by the RS quickly, but include a claim that is a reference to information
at the AS and introspect that in parallel, that also deals with a problem that
occurs if you have multiple AS for one RS.
At this stage I can only say I agree JWT can be a useful token container
indeed :-)
I don't think that we should go into all the possible options in this spec,
perhaps that could be in a implementers guide.
I'm also curious about the option where the whole token responses are JWE
encrypted even if TLS is used, with the assymetric key cases; thus allowing for
the key being always in a plain base64 URL encoded form (in the case of the key
distributions) but also in other cases I guess...We will offer this option for
our users as an extension but I wonder if someone else here would find it useful
If the proof key is JWE encrypted to the client what would be the point of
encrypting the token as well?
I don't think I am quite getting your use case.
Sorry; I was just referring to a possibility of aligning token responses
with the pure HTTP content negotiation mechanism. IMHO it won't be
controversial. Consider this for an access token request/response with
the symmetric POP key:
Accept: application/json
non-TLS
{"access_token":"compactJwsWithJweJwkInside", "key":"jweJwk"}
or TLS:
{"access_token":"compactJwsWithJwkInside", "key":"Jwk"}
vs
Accept: application/jose
non-TLS
JWE-payload
TLS:
JWS payload
with
{"access_token":"plainJwtWithJwkInside", "key":"Jwk"}
being the actual wrapped content in both cases.
As far as the client is concerned its processing model remains
consistent (i.e, it does not deal with treating specific token response
parameters as JWK or JWS payloads), with the client filters taking case
of unwrapping a JOSE payload for the client code to deal with the actual
data.
Encrypting to the client only works if it has a provisioned asymmetric key
pair. In the symmetric case the client provides it's secret as part of the
request to the token endpoint via http BASIC authentication, so anyone
intercepting the https would have that key unless the client is using the JWK
assertion flow for authentication (more of an edge case but supported in
Connect)
Are you thinking that the client would not use it's key for authentication but
the AS would encrypt all or part of the response to the key to prevent man in
the middle?
At one point of time I did think that may be a client's own secret would
be used for the encryption indeed :-), I referred to it earlier as a
case of the direct encryption, but then realized, and as you pointed out
that it would indeed make use of that secret as part of the Basic scheme
risky;
I don't have enough experience to know how realistic is a man in the
middle attack over HTTPs but I do think that people are generally open
to the idea of the double protection (meaning that even JWE over TLS
will work :-))
I will admit looking at it now Sec 4.2 needs to be fleshed out around what keys
you could use to encrypt the JWE encoded JWK. I was thinking asymmetric keys
but in principal you could use a symmetric key as long as it is not the one
used for authenticating the client.
Can this extra symmetric key be referred to as a key obtained out of
band during the registration, or even mentioned as part of the dynamic
registration process...It's like an extra key distribution, during the
registration the client gets its secret plus a POP symmetric key
Thanks, Sergey
John B.
Cheers, Sergey
On 07/11/14 14:15, John Bradley wrote:
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
