Subject: [OAUTH-WG] Token Introspection and JWTs

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 28 Feb 2018 08:48:33 +0100

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. 

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.

I’m looking forward to get you feedback.

kind regards,
Torsten.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 28 Feb 2018 11:53:43 +0200

> 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: a…
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

---

From: Mark Dobrinic <[email-masked]>
Date: Wed, 28 Feb 2018 11:49:19 +0100

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

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 28 Feb 2018 18:16:27 +0200

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

---

From: Mark Dobrinic <[email-masked]>
Date: Wed, 28 Feb 2018 18:50:57 +0100

Hi Vladimir,

Yes, the settings that the AS uses to create that JWT are established
out-of-band. Being the issuer of the token in the first place, I'd like
to see it being authoritative in choosing a secure way of doing so.

Thinking of it, the suggestion to advertise those cryptographic
properties of signed or encrypted tokens could be a good follow up for
this, so a client can inform itself of what to expect.

Negotiating which cryptographic properties to use on a per-client basis
for a client-authenticated request to the introspection endpoint could
also be something to consider (maybe as a property for dynamically
registered clients?) but we haven't felt the urge to take that plunge
just yet. If we are be missing out on some insights there, I'd love to
hear more on that.

And thanks for those compliments, I'll pass them on my colleague who
wrote that!

Cheers,

Mark