Re: [OAUTH-WG] JWS Access Token concerns

Sergey Beryozkin <> Wed, 24 February 2016 11:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 799331A906E for <>; Wed, 24 Feb 2016 03:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3YMgHj3T7Ex5 for <>; Wed, 24 Feb 2016 03:47:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB16B1A9067 for <>; Wed, 24 Feb 2016 03:47:21 -0800 (PST)
Received: by with SMTP id b205so30982005wmb.1 for <>; Wed, 24 Feb 2016 03:47:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pyAFEjbZZXS5FxUOn2Us0mJG/u9gbih5NPKujf14qVI=; b=NeFObEJONY+IqymYHdzd4bmm+QMoXE1QQpMof22I8B0eG3R9BlN9iCNifLmpep1fR2 TIN7zhsWBnM/DxJnW8YPL6ovLoaBmM3NHe0G4sFGHnbpl3Q9hIwoX1rQbSREXVw4JiWo tk6jwE2FtFvz8T3h9Ms1/B7pMmPE2uLDQDLzjAO7Uaz59W1YbA6sgE946Ca6Cgb8WvJm 9F+2KnMyAe73A5/A2eEQGhzCr0dAPawHprx9j7n5+EW6scdHyk0kc7tzle8N8weLgnix wHbfl9jh5PKngyq7TUa1PU69EDvDNA0PpUhEJ6UVuHuoOXhetaGcB8o/S27ySgoZNtfQ UZIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pyAFEjbZZXS5FxUOn2Us0mJG/u9gbih5NPKujf14qVI=; b=FRxufGWtxeX0E2A8PrNbxvSG9VtHBB35hU9bhj7NslhWu/wOXtw7tsrJ99oly1gvwo IpzfLMgZ+iaaamybYM5vzrwr+vEj8yTnzI48OENp+thl27wfopDWo9TWXGlZXb+/xq4f eoQY2gmUxvSwGUgt9brqpm+J+xzd/kE2sqyA90A/Mt/oUr0DKAOPnWJETTCXYZSjBCDr wTbktRy66p4fgjjIpMWeP9Avc1kt9PeLTpEY3gaNyxDpBGGhvcnWgGWqwU5ZqekCVPFj qIA0lYCurxQgmNdbAUnJNtGvFE8k/5OhXDe7IMWkQXpDMknqDaGWHTEkWi0d4ZS71GcV KPyA==
X-Gm-Message-State: AG10YOQlaVZiM6FJ9uciID/WzNK6yPb/+R3jAj7eagTc5oWR9gYb5pi22lJWmGZT7/y+ug==
X-Received: by with SMTP id fe7mr38483685wjc.50.1456314440227; Wed, 24 Feb 2016 03:47:20 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t12sm30826561wmt.20.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 03:47:19 -0800 (PST)
References: <>
To: "" <>
From: Sergey Beryozkin <>
X-Forwarded-Message-Id: <>
Message-ID: <>
Date: Wed, 24 Feb 2016 11:47:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OAUTH-WG] JWS Access Token concerns
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2016 11:47:24 -0000

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


-------- Forwarded Message --------
Subject: Re: [OAUTH-WG] JWS Access Token concerns
Date: Wed, 24 Feb 2016 13:34:47 +0200
From: Vladimir Dzhuvinov <>
Organization: Connect2id Ltd.
To: Sergey Beryozkin <>

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:
>>> 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 mailing list

Vladimir Dzhuvinov ::