Q: Introspection endpoint?

[Peperud]

How should it be used?

I have Authority, ClientId, ClientSecret and NameClaimType specified in IdentityServerBearerTokenAuthenticationOptions and I still get an Unathorized response.

Here's the log

What am I missing? Am I supposed to have a scope with the same name as the client?

[brockallen]

Use the credentials on the Scope configuration (not the Client configuration)

[Peperud]

@brockallen So there must be a scope with the same name as the client id and a password for it? And then the ClientSecret, specified in the IdentityServerBearerTokenAuthenticationOptions will be matched against the password for the scope with the same name as the client id?

Using the above arrangement, I'm getting

The response comes out as 200, but "not active" ?

[brockallen]

The token introspection endpoint is used by your web api. The web api is modeled with the Scope configuration object model in IdentityServer. Thus the web api (aka scope) has an "identity", so to speak, when trying to use the token introspection endpoint. The Scope configuration object model already has an identifier (https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Models/Scope.cs#L34), which is used as the ClientId in the access token middleware config, and a set of credentials (https://github.com/IdentityServer/IdentityServer3/blob/master/source/Core/Models/Scope.cs#L87) which can be used as the ClientSecret in the access token middleware config.

[Peperud]

Thanks @brockallen So...whoever wants to validate the token has to authenticate. But the only "actors" that can authenticate on the server are users and clients and the access token consumer is neither. And even if it was a say client, there's no reason for granting one client the right to validate tokens issued to another client.

So the access token consumer is given its own "identity scope" and a corresponding secret. The "identity scope" must be present (in addition to any other scopes) in the access token. The token consumer than is requesting token validation by supplying the token and authenticating with its "identity scope" and secret.

Did I get that right?

[leastprivilege]

Identity scopes does not make sense to me - typically it would be an api that wants to introspect the token - not the client application. That said we don't enforce this.

[Peperud]

I feel I'm perhaps going in a wrong direction and would appreciate some proper stirring...

There's my line of thinking:

The access token can have multiple scopes in it, or even if it is a single scope, that single scope can be different for the different tokens coming to the same service (full_access, partial_access1, partial_access2, read_only etc.).

So without some sort of dedicated, perhaps "just for validating" scope, that is expected to always be present, how would the bearer token middleware sitting in front of the web api be able to use the introspection point to validate the token?

[leastprivilege]

OK - you are saying that it is a problem that the introspection endpoint strips out all the scope claims besides the "current" one. Right?

I agree with that - lemme think about it.

[Peperud]

@leastprivilege Yes.

And it goes a little deeper than that... Perhaps I'm missing or misunderstanding the the purpose of the introspection endpoint. For me it is a way an application (trusting the endpoint) can validate a token it has received. It is the only way a reference token can be validated. I don't understand the reason, why the validation process would alter the token I have received at all?

The other thing is about how a web api should be secured. I guess with separately exposed microservices api, there's no reason to send but a single "access/no access" scope. The auth middleware than would have to "know" only this single "access/no access" scope. But in reality, an access token can contain several scopes (in various combinations), that the downstream api can use to make decisions. How would the bearer token middleware, receiving a reference token know which scope/scope password it should send along to use the introspection endpoint to validate the token? In my mind the only way it could work is if the bearer token middleware sitting in front of the api knows a special "api identity" scope, and this "api identity" scope is always present in the access token.

[leastprivilege]

Have you read the spec?

Sent from my iPad

On 14 Dec 2015, at 20:12, Peperud notifications@github.com wrote:

@leastprivilege Yes.

And it goes a little deeper than that... Perhaps I'm missing or misunderstanding the the purpose of the introspection endpoint. For me it is a way an application (trusting the endpoint) can validate a token it has received. It is the only way a reference token can be validated. I don't understand the reason, why the validation process would alter the token I have received at all?

The other thing is about how a web api should be secured. I guess with separately exposed microservices api, there's no reason to send but a single "access/no access" scope. The auth middleware than would have to "know" only this single "access/no access" scope. But in reality, an access token can contain several scopes (in various combinations), that the downstream api can use to make decisions. How would the bearer token middleware, receiving a reference token know which scope/scope password it should send along to use the introspection endpoint to validate the token? In my mind the only way it could work is if the bearer token middleware sitting in front of the api knows a special "api identity" scope, and this "api identity" scope is always present in access token.

— Reply to this email directly or view it on GitHub.

[Peperud]

@leastprivilege

Yes.

To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750].

The specs also state that the endpoint may not return all the scopes.

The authorization server MAY respond differently to different protected resources making the same request. For instance, an authorization server MAY limit which scopes from a given token are returned for each protected resource to prevent protected resources from learning more about the larger network than is necessary for its operation.

My understanding is that the first part is done by extending the scopes with scope secrets and using these to authenticate the requests to the introspection endpoint. That's why I called it "api identity/access" scope. The bearer token middleware must know the "api identity/access" scope and secret.

The second quoted part seem to be unconditionally enforced, leaving only the "api identity/access" scope in the response. Which basically means that an application working with reference tokens would never be able to get more than one scope.

...or I am missing something?

[leastprivilege]

right - as I mentioned I am gonna introduce a config setting to control part 2. soon.

[leastprivilege]

https://github.com/IdentityServer/IdentityServer3/pull/2306

give it a try

[Peperud]

@leastprivilege Thanks Dom.