Re: [OAUTH-WG] JWS Access Token concerns

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 23 February 2016 19:41 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FC21A6FC0 for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 11:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiOn6vo6U8Fq for <oauth@ietfa.amsl.com>; Tue, 23 Feb 2016 11:41:43 -0800 (PST)
Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179B01A1A27 for <oauth@ietf.org>; Tue, 23 Feb 2016 11:41:43 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-01.prod.phx3.secureserver.net with id Mvhh1s00715ZTut01vhiAh; Tue, 23 Feb 2016 12:41:42 -0700
To: oauth@ietf.org
References: <56C7702B.2000401@gmx.net> <BY2PR03MB442E9BF84AFA890378C5116F5A00@BY2PR03MB442.namprd03.prod.outlook.com> <56C77D92.5050203@pingidentity.com> <88DE9988-2CDB-4206-86CE-E7EFF93FB27A@oracle.com> <CAAP42hD96u0Nepdo8YcHeXEo2v1Mo=a_Zo4OcS9ppu7rU-=8Ag@mail.gmail.com> <1756F20F-CE42-4523-BE8E-450762D34697@ve7jtb.com> <05af01d16d4a$20230af0$606920d0$@nri.co.jp> <0CD2EAC7-A9B6-44AC-9644-7E20E345464F@ve7jtb.com> <CAAP42hDFiY-YiuAJfs43dyg0WoJH+dBe5CmdwKczirUKoD6fJw@mail.gmail.com> <56CC93AF.1060105@gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56CCB5F4.2060105@connect2id.com>
Date: Tue, 23 Feb 2016 21:41:40 +0200
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: <56CC93AF.1060105@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080506020408040901020903"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/W2oVj-3WWuvwAjMBR0xBRxh4ln0>
Subject: Re: [OAUTH-WG] JWS Access Token concerns
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 19:41:44 -0000

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