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 >>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
