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 On 28/02/18 17:16, Vladimir Dzhuvinov wrote: > 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 >>> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
