Re: [OAUTH-WG] JWS Access Token concerns

[Sergey Beryozkin <[e-mail]>]

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 <[e-mail]>
Organization: Connect2id Ltd.
To: Sergey Beryozkin <[e-mail]>

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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Vladimir Dzhuvinov :: [e-mail]