Duende IdentityServer does not validate introspection requests for Refresh Tokens

[mikbazz19]

In the RFC document for OAuth 2.0 Token Introspection (https://www.rfc-editor.org/rfc/rfc7662), mentioned that introspection requests can be validated for Access and Refresh tokens. But after going through the open-source code for Duende IdentityServer it seems that Duende IdentityServer does not validate the introspection request for refresh token. Thought of sharing the same since generally, the introspection requests are being validated against Access token (but Refresh token is not out of scope).

[mikbazz19]

Any update on this?

[leastprivilege]

it seems that Duende IdentityServer does not validate the introspection request for refresh token

What makes you think that? And what exactly do you mean with "validate" ?

[leastprivilege]

Oh sorry - now I see. I always read "revocation" and not "introspection".

Seems we haven't implemented introspection for refresh tokens. What would be your use case for that?

[mikbazz19]

I was just hitting our IdP's (which is using Duende IdentityServer) introspection endpoint against an active refresh token. Observed that it is only returning the active:false response, not like the response received from an active access token. Cross-verified it with Oauth RFCs, there it is mentioned that introspection requests can be validated for Access and Refresh tokens.

Are there any plans to implement introspection for refresh tokens to make it complaint with OAuth 2.0 Token Introspection RFC?

[leastprivilege]

What's your (business / technical) use case?

[mikbazz19]

Currently there aren't any from my end. Just exploring OAuth 2.0 resources and endpoints while came across this issue.

[leastprivilege]

OK - thanks! We didn't have a real use case either.

[brockallen]

Ok, we can look at add this on our backlog.

[VersaSuite]

I came across this same issue durring ONC testing. It not a 'real' use case but is required for g(10) certification.

9.10.06: Health IT developer demonstrated the ability of the Health IT Module / authorization server to validate token it has issued. • Demonstration required – part of g.10.6.2 Step #2 (Token Introspection) • This is required and is different than token revocation. An example use case would be if you found out a hacker had gotten access to your FHIR server, you need to have a way to check status on and revoke their access and refresh tokens. Introspection will be demonstrated during the token revoke test by showing functionality to get status on previously used access/refresh token. Some developers created a GUI admin console to do introspection, but Postman or another API client can be used for this demonstration. SMART on FHIR has a provision for doing token introspection

[alexzautke]

We at Firely are required to conform to the same requirements mentioned by @VersaSuite above. I understand that it there is almost no realistic use case behind it. Still for compliance reasons it would be great to get this feature back on the roadmap.

[brockallen]

We'll have a look for our 7.0 release. Thx

[brockallen]

So looking at this, validating a refresh token is a bit more complicated than an access token. For an access token, the caller will only ever be the API (so our ApiResource object model and associated credentials), but a refresh token will be a client making the call, thus using its client credentials.

Consequently, this means the client could be passing either an access token or refresh token. The spec doesn't say, but to me this means an API would only ever be passing an access token (it doesn't make sense to me why it would have a refresh token). So this adds a bunch more validation and complexity here. So we will not allow an API to validate a refresh token, and a client can pass either and we'll need to ensure the client is the one to whom the token was issued.

I just wanted to confirm with those of you that have test suites you need to pass... are the above constraints and validation logic in agreement with your expectations?

Also, the claims you will get back from a refresh token won't be exactly the same as an access token because of things like resource indicators. So the claims for a refresh token will be minimal. Let us know if there are certain things you really need or want.

[brockallen]

PR has been created. Please have a look and provide any feedback. Thanks.

[VersaSuite]

The requirements for certification are vague at best. The implication is that you (the certified entity or user thereof) are able introspect a token (access or refresh). Beyond that there is no guidance. My experience is this is a yes or no requirement, "Is this token valid?".

[alexzautke]

Agree. During certification testing you might be asked by your certification body to show that the introspection endpoint is working by providing both types of tokens (access and refresh token).