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