Re: [OAUTH-WG] Token Introspection and JWTs

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 28 February 2018 16:16 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0724112D0C3 for <oauth@ietfa.amsl.com>; Wed, 28 Feb 2018 08:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 BhgWoFWLasKJ for <oauth@ietfa.amsl.com>; Wed, 28 Feb 2018 08:16:29 -0800 (PST)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565D3124B17 for <oauth@ietf.org>; Wed, 28 Feb 2018 08:16:29 -0800 (PST)
Received: from [192.168.0.107] ([78.130.190.73]) by :SMTPAUTH: with SMTP id r4P5eSpYHCHhTr4P6eZosX; Wed, 28 Feb 2018 09:16:29 -0700
To: Mark Dobrinic <mdobrinic@cozmanova.com>, oauth@ietf.org
References: <74F11CBE-5ED8-4B2C-B219-F9036E07B3B9@lodderstedt.net> <1a80c619-51dd-b6cf-8125-057da778ecf0@connect2id.com> <b76ea6de-7392-2845-f106-f2cba1da0eb1@cozmanova.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <a5ff099e-5f64-fcda-3a9d-950c11141134@connect2id.com>
Date: Wed, 28 Feb 2018 18:16:27 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <b76ea6de-7392-2845-f106-f2cba1da0eb1@cozmanova.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000008050802030400040402"
X-CMAE-Envelope: MS4wfEtFEzPmVpRtPETiPDlLmTrwp8y+lIxS+Hr+q01BtKc0oM9vNb7h5k1/bOdhLJv2x3wjwWhI6Gfjk6vjOuETh8HE7Wx5HjwhTSojBzC+sgkSG567tQRl 0JKOFA1Mwc7h3z7rdK3SrZ7/QfCblM+wVuZGUmDkHo+jkOyaJb54TAvDQlIFQTX6yseN6GugO5uGn4Bpyq0hizVds35DfsvcUBA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-0gPZiR5JjlEcKqf13Q1UOjpk-Y>
Subject: Re: [OAUTH-WG] Token Introspection and JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 28 Feb 2018 16:16:31 -0000

Hi Mark,

The Nginx module is superbly documented, well done!

I suppose there's a set JWS alg for the issued tokens, which is agreed
in advance?

Vladimir

On 28/02/18 12:49, Mark Dobrinic wrote:
> Having the introspect endpoint support a response Content-Type of
> `application/jwt` is exactly what we're doing in Curity. We actually
> gave it a cool name in the process, a Phantom Token ;)
>
> Doing things this way has proven highly useful in usecases where
> customers have high throughput requirements, and is a perfect fit in the
> HTTP model. As such, it wouldn't need any more discoverable endpoints,
> but piggybacks a AS-specific JWT token issuance setup.
>
> It's actually super simple to achieve, and as such we're planning to
> write it down as an extension to the RFC and submit that to the
> workgroup. Reason for that would be to have a standardized way of
> switching from reference- to self-contained token format, something we
> see valuable enough time to justify that.
>
> Here's what we already did with that:
> https://github.com/curityio/nginx_phantom_token_module
> https://curity.io/product/token-service/#phantom_tokens
>
>
> On 28/02/18 10:53, Vladimir Dzhuvinov wrote:
>> On 28/02/18 09:48, Torsten Lodderstedt wrote:
>>> Hi all,
>>>
>>> I have an use case where I would like to return signed JWTs from the authorization server’s introspection endpoint. In this case, I would like to give the resource server evidence about the fact the AS minted the access token and is liable for its contents (verified person data used to create a qualified electronic signature).
>>>
>>> Although token introspection more or less provides the RS with the content of a JWT, RFC 7662 only supports plain JSON. I talked to Justin and his recommendation was to use use a  header “accept: application/jwt” to ask the AS for a signed JWT as response instead of "application/json“. We could do this but clearly it would be a proprietary solution. 
>> Justin's suggestion would be relatively easy to implement. The only
>> small downside I see is that it doesn't allow resource servers to choose
>> a crypto algorithm for the issued JWT, which has become the norm for
>> this kind of things in OAuth and OIDC.
>>
>>> I would like to know whether anyone else has the same or similar requirements and whether it would make sense to specify an extension to RFC 7662 for JWT responses.
>> Because of the requirement for resource servers to authenticate (or
>> submit a token authz) when they make an introspection request, we let
>> them register as a client, using std client registration. In that case
>> to let an RS register preferred JWT algs for the introspection response
>> we could have parameters
>>
>> introspection_response_signed_response_alg
>> introspection_response_encrypted_response_alg
>> introspection_response_encrypted_response_enc
>>
>> (naming follows pattern for ID token and UserInfo algs)
>>
>> Vladimir
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>