We don’t include the scopes or identity information in the token itself, so as to prevent it from leaking to parties that shouldn’t need it.
The main benefit of introspection is liveness, but it also lets you reference data tied to the token that you don’t want to ship in the token itself. At the end of the day, it’s a trade off as to what you want to put into the token and what you want attached as a reference. Good news is that you can do both together and use the strengths of each. — Justin > On Mar 13, 2016, at 10:36 PM, Andrea Ceccanti <andrea.cecca...@gmail.com> > wrote: > > Hello, > > interesting thread, thanks. > > Assuming the scopes are included in the token, the main purpose of call to > the introspection endpoint is to ensure > the token hasn't been revoked? > > We are considering a deployment where a RS can trust multiple AS, and having > a JWT as access token, with > issuer, scopes and basic identity information included seems to solve our > issues. > > Thanks, > Andrea > > > > > 2016-03-13 9:03 GMT+08:00 Justin Richer <jric...@mit.edu > <mailto:jric...@mit.edu>>: > What we've done in deployments is to combine JWT and introspection. You have > all of your servers issue signed JWTs that include the "iss" (issuer) in the > body, signed with the key of the AS. The tokens also include a random "jti" > field. The RS submits the token to the introspection endpoint of the server > identified in "iss", but only after validating the signature and other basic > bits of information. If the introspection call comes back positive (and with > the right scope, client, and resource owner information), the resource is > served. > > -- Justin > > > On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote: >> Hello, >> >> I have a question. >> >> If there exist multiple authorization servers that can issue access tokens >> for one resource server, when the resource server receives an access token >> from a client application, as the first step, the resource server has to >> determine which authorization server to use for access token introspection. >> >> Is there any standard way to determine which authorization server to use? >> >> There may be several ways, for example: >> >> (1) Embed information about the access token issuer in the access token. >> (2) Add a request parameter to identify the access token issuer. >> (3) Separate protected resource endpoints for each authorization server. >> >> If there is a standard way, I'd like to know it. >> >> Best Regards, >> Takahiko Kawasaki >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
