Re: [OAUTH-WG] Token Introspection and JWTs

2018-02-28 Thread Mark Dobrinic
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

Re: [OAUTH-WG] Token Introspection and JWTs

2018-02-28 Thread Vladimir Dzhuvinov
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

Re: [OAUTH-WG] Token Introspection and JWTs

2018-02-28 Thread Mark Dobrinic
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

Re: [OAUTH-WG] Token Introspection and JWTs

2018-02-28 Thread Vladimir Dzhuvinov
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

[OAUTH-WG] Token Introspection and JWTs

2018-02-27 Thread Torsten Lodderstedt
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