Introspection endpoint

[snothub]

Reading the documentation, only scopes contained in the token can introspect it. This has me wondering:

• given an api with required scopes set to "customers" and "orders", what client id and secret should the api use to introspect the token? If it is "customers" + secret, it won't be able to introspect a token containing "orders" scope only, and vice versa.

My thinking is that if an api can support any number of different scopes in the tokens it receives, which one should be the introspecting scope? Is this introducing a requirement of a scope to be present in the token for introspection purposes only?

[brockallen]

Yes, it could get somewhat complex. This is why we have this property on the Scope config: https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Models/Scope.cs#L92

[snothub]

Right, meaning one can define a scope used purely for introspection and that scope doesn't have to be present in the token being introspected?

Den ons. 2. mar. 2016, 18.16 skrev Brock Allen notifications@github.com:

Yes, it could get somewhat complex. This is why we have this property on the Scope config: https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Models/Scope.cs#L92

— Reply to this email directly or view it on GitHub https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation/issues/81#issuecomment-191330641 .

[brockallen]

Never tried that approach, but it sounds plausible.

[snothub]

I thought AllowUnrestrictedIntrospection prop was there to allow introspection of other scopes in the token while still itself being required present in the token. If that's the case, then wouldn't we have to always include a scope in all tokens that would be used for introspection?

Ideally, an api should be able to introspect the token somehow without knowing in advance what scopes were present in the token (because it might have many/no required scopes). But that would require a scope that might not be in the token.

So which one is it?

[brockallen]

I'd say try it and find out.

[snothub]

I'm just trying to figure out the best practice here before going in any direction, but I'm still at a loss.

The point of authenticating the introspection is presumably to not allow anyone do it. But often times, what scopes are in a token reaching an api is an unknown, so I don't see how one can specify one specific scope and secret as identity information for introspection (with the exception of an api requiring only that one specific scope, which is not often I think).

So if an api requires one of five specific scopes, what should be used for introspection? A new scope for that purpose only? Would that work and is it wise? What then with ten other apis in an eco-system? Should they all use the same introspection scope? Should it not be a scope thing at all, but a new client flow? I don't know, but please help me make sense of it.

[leastprivilege]

You have to chose the "primary scope" for that API - and give that scope the right to see other scopes in the token

[snothub]

So the "primary" scope would always have to be present and have access to other scopes. Meaning the "RequiredScopes" property on the options object changes from "any of these" to "any of these except this one has to be there". Right?

[leastprivilege]

yes