Hi All
I inadvertently started a private thread when replying to Vladimir, I
spotted it only now. Forwarding it back to the list.
Vladimir - many thanks
Sergey
-------- Forwarded Message --------
Subject: Re: [OAUTH-WG] JWS Access Token concerns
Date: Wed, 24 Feb 2016 13:34:47 +0200
From: Vladimir Dzhuvinov <vladi...@connect2id.com>
Organization: Connect2id Ltd.
To: Sergey Beryozkin <sberyoz...@gmail.com>
I see, tokens encrypted to self! Yes, that can work pretty well. And you
can still have revocation, by keeping a table or cache of the revoked
tokens (identified by "jti" or hash).
Happy coding!
On 24/02/16 12:35, Sergey Beryozkin wrote:
Hi Vladimir
Yes - it helps :-) I was not really planning to start a 'campaign'
against JWS tokens but rather reacted to the fact that I was able to
see more inside the JWS token on the OAuth2 client side than were
visible in the standard access token response (access_token,
expires_in, etc, with access_token carrying a lot more inside itself).
We are planning to support self-contained tokens but right now I'm
inclined to offer a JWE option only (without JWS) and also a JWS if
needed (of course without sticking the sensitive parts inside of it :-)).
The reason I think a JWE-only option is effective is because I'm not
sure RS needs to do an immediate validation it was issued by a given
AS - it can simply post this JWE token to AS it is linked to and AS,
if it can decrypt it using its private key will tell back, using the
standard introspection response all RS needs to know, no need to share
the encryption key with RS.
Same for JWS tokens. Though not sure how PoP tokens will be validated
- we haven't started using them yet and as far as I recall the
introspection spec is not talking about them.
Cheers, Sergey
On 24/02/16 10:19, Vladimir Dzhuvinov wrote:
RFC 6749 is essentially a framework (it even says it in the title),
which means there are plenty of ways to shoot yourself in the foot :)
If our experience can be of help: The Connect2id server can issue
identifier as well as JWT access tokens, depending on policy.
The JWT is signed by default. There are no claims in it that the client
doesn't know already - subject, client_id, granted scope.
There is also an optional "dat" (data) field if the AS / OP wants to
stick additional data for use by the RS.
If integrators want confidentiality of that "data", the JWT can be
additionally encrypted with a key that is shared between OP and RS
instances. That way the token authenticity can still be verified by RS
after decryption. The encryption key is shared, based on the assumption
that the "data" is shared knowledge between AS / OP and all RS
instances. There haven't been requests from customers to make data
confidential for a specific RS (yet).
Now back to reading more sec papers :) Universe must have a way through
the latest sec issues.
Vladimir
On 24/02/16 11:47, Sergey Beryozkin wrote:
Hi
On 24/02/16 05:07, Vladimir Dzhuvinov wrote:
Hi there,
On 23/02/16 23:35, Sergey Beryozkin wrote:
Hi Vladimir
May be I did not express my query well.
When we talk about the access tokens, it is what OAuth2 access token
service returns to the client - it does not have to be JWT, right ?
No, as long as it can work as a token. That is, allow the RS to
determine whether the client can run the request or not, and be sure
that token (and the associated authorisation) come from the AS.
You've probably looked at the spec:
http://tools.ietf.org/html/rfc6749#section-1.4
http://tools.ietf.org/html/rfc6749#section-7.1
Thanks for your patient explanation, but I'm sorry I was not looking
for that :-), I'd like to believe I've got what access tokens are for
and how they are supposed to be validated :-). I'm sorry, it is my
fault.
It is perfectly fine to return a DB pointer, OAuth2 talks about such
access tokens.
Yes. Identifier (key) based tokens have the effect that revoking them
has an immediate effect, so for high security apps their are optimal.
But processing them on the RS side them takes a network call to the
inspection point.
RSA signed JWTs take on the other hand about 50us to verify.
The client should not care. The client is not supposed to start
processing access_token the way it can process the id_token.
It is only something the client will use when accessing RS and
clearly
the 'plain' bearer tokens are full citizens here.
What I'm saying that in fact a client can easily read a JWS-signed
access token content - today I saw some internal properties of a 3rd
party provider which I'm not sure are meant to be visible to the
client at all.
If that's sensitive information that shouldn't be seen by client or
user, then I suggest you report your finding.
This is what I'm doing here. I've no time engaging with the individual
provider's implementers but rather is trying to ask a question to the
group, how sensitive can it be that someone like me can just paste a
content of the JWS token into my code and check how AT is represented
internally.
I don't mind much - but it seems it goes completely against the
OAuth2
saying the access tokens are supposed to be opaque to the client -
JWS-signed tokens are not.
Well, the exact qualifier is "usually opaque" :)
Well, it is not :-)
Either way, thanks for the time...
Sergey
The string is usually opaque to the client.
Vladimir
Sergey
On 23/02/16 19:41, Vladimir Dzhuvinov wrote:
Hi Sergey,
JWE will indeed make the token content confidential to clients.
However,
without a proper signature (RSA or EC, HMAC in JWS doesn't
qualify), the
RS cannot establish the origin of the token. With symmetric crypto
(e.g.
JWE alg=dir) anyone who has the shared key will be able to create a
token (e.g. other RS in the domain that rely on the AS). With
asymmetric
crypto, anyone with access to the public key of the RS will be
able to
encrypt for the recipient.
Hope this helps,
On 23/02/16 19:15, Sergey Beryozkin wrote:
Hi
Some OAuth2 providers may return self-contained access tokens which
are JWS Compact-encoded.
I wonder is it really a good idea and would it not be better to
only
JWE-encrypt the tokens. I'm not sure JWS signing the claims is
necessarily faster then only encrypting the claims, assuming the
symmetric algorithms are used in both cases.
For example, my colleague and myself, while dealing with the issue
related to parsing an access token response from a 3rd party
provider
were able to easily check the content of the JWS-signed
access_token
by simply submitting an easily recognized JWS Compact-formatted
value
(3 dots) into our JWS reader - we did not have to worry about
decrypting it neither the fact we did not validate the signature
mattered.
But access tokens are opaque values as far as the clients are
concerned and if the introspection is needed then the introspection
endpoint does exist for that purpose...
Thanks, Sergey
_______________________________________________
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
--
Vladimir Dzhuvinov :: vladi...@connect2id.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
