Wrong ApiResource selected for reference token; token refused

[paulguz-datapa]

We have implemented reference tokens in our IdentityServer v7 instance.

We have a few ApiResources defined. One of these, "Developer.API", has a scope (Developer.Scope) not used anywhere else.

"Developer.API" is defined as such:

new ApiResource("Developer.API", "Developer.Scope", new[]{ "tenant", "user" } )

Our reference token has "Developer.API" defined as the audience (using the Token.Audiences property, and also the "aud" claim), and only has one scope, being "Developer.Scope". Yet, the token is not authorised, with the error:

ClaimsAuthorizationRequirement:Claim.Type=scope and Claim.Value is one of the following values: (Developer.Scope)

If I add "Developer.Scope" to another ApiResource (the first defined the list), the token is accepted.

This seems like a bug, or what am I doing wrong? My understanding is that the audience stated in the token, and the scopes requested, define which ApiResource is used. But it is just the first ApiResource in the list that appears to be selected.

[RolandGuijt]

Just to make sure: The second constructor parameter of the ApiResource class is the display name used for the resource. It is used in the consent screen e.g. but it doesn't play a role in the auth process. "Developer.Scope" should be defined in the Scopes property of ApiResource.

Assuming that is in place: when the client requests "Developer.Scope", the value of the aud claim should be "Developer.API". So the scope that is requested determines which ApiResource (where its name is the value for aud) is used.
If this doesn't resolve the issue please provide us with the full configuration code on the IdentityServer side and the configuration of OIDC handler on the client side and the BearerToken handler on the API side.

[paulguz-datapa]

@RolandGuijt Thank you for your help. Indeed, I had mistaken the second parameter for a Scope, and fixed the ApiResource definition accordingly.

The other part of the puzzle was that did not realise that the ApiResource must be the same as the ClientId defined for the Instropection client. Is that by design?

[RolandGuijt]

Yes. Introspection is typically used by APIs to validate an incoming token. Since the API is not a client and the introspection endpoint requires authentication per spec, the ApiResource name is used to authenticate together with a secret which can be defined in the ApiResource.

[paulguz-datapa]

@RolandGuijt Thanks for the explanation. It makes sense now, and it should have occurred to me sooner that if I'm using the Api Secret as the Client Secret for introspection, it follows that the Client Name should be the Api Resource name. This isn't explicit in the doucmentation though; I wonder if that could be changed? And in ther IdentityModel's OAuth2IntrospectionOptions, would the properties not be more helpfully named ApiId and ApiSecret, rather than ClientId and ClientSecret?

[RolandGuijt]

I agree it's confusing but the intropection endpoint can also be used by clients that somehow don't have the ability to verify the token themselves. Also when the API uses it, it could be seen as the client for the endpoint. For now we'll keep the property names as is, also because this would mean a breaking change, but you're right on the documentation point. I'll make sure that gets improved.

[RolandGuijt]

I've clarified the docs. Thanks for taking the time to make us aware!
https://docs.duendesoftware.com/identityserver/reference/endpoints/introspection/