Is the /introspect endpoint meant for the OAuth Client to call, or the OAuth Resource Server to call?

[jrahhali]

I’m learning about the OAuth /introspect endpoint as a means to validate an Access Token.

I’ve read online that the /introspect endpoint is intended to be called by an OAuth Resource Server. For example, an OAuth Client might call a Resource Server, providing an Access Token, and the Resource Server would call the /introspect endpoint to make sure the token is active/valid.

However, the /introspect endpoint with Okta requires the OAuth Client credentials to be provided with the request (either as a basic auth header, or in the case where there is no client secret, just a client_id request param).

So, how can the Resource Server call the /introspect endpoint when it doesn’t have the OAuth Client ID and/or secret? This is making me wonder if the /introspect endpoint is meant to be called by the OAuth Client instead, which to me, doesn’t seem as useful.

I came accross the “What does the client_id and client_secret request parameters in the /introspect endpoint signify?” Okta article, in which it says:

The resource server can use the /introspect endpoint to check if the token is valid or not. This resource server needs to be a registered client application at Okta. The request parameters - client_id and client_secret of /introspect endpoint refer to this client application that is the resource server.

How can a resource server also be a client application in Okta? Maybe I"m getting terms confused, but I thought an “Okta Application” entity represented/mapped-to an OAuth Client, and an “Okta API” entity represented an OAuth Resource Server and Authorization Server?

[andrea]

As you saw in the documentation, the /introspect endpoint requires client authentication in order to be used to validate a token is still valid. If your resource server is looking to remotely validate access tokens, it will need to include the client credentials for the application that was used to generate the token.

If you are looking to protect a resource server with OAuth tokens, you may prefer using local token validation instead as described in this guide. As it mentions, this can be done faster and without incurring additional network events like you would when using /introspect instead (remote validation).

[jrahhali]

If your resource server is looking to remotely validate access tokens, it will need to include the client credentials for the application that was used to generate the token.

Thanks for sharing. Are you aware of any Okta documentation suggesting how a Resource Server might obtain the Client credentials? Off the top of my head, I’m thinking the Client could send the credentials as custom headers when making an API call to the Resource Server. But I’m just wondering if Okta has any official stance on this? I can’t find any.

[gpadma]

Hi @jrahhali,

If the resource server wants to use /introspect endpoint for validating the access token, then there needs to be a registered application at okta for the resource server and the client credentials in /introspect refer to this app’s client credentials.

[gcgc]

hi, all,

this is a very legitimate question. I understand the resource server needs to call /introspect endpt from time to time to check the tokens have not been revoked behind the scene, apart from the local check, as suggested by Okta doc,
https://developer.okta.com/docs/guides/validate-access-tokens/dotnet/overview/#validating-a-token-remotely-with-okta

but as the endpt takes client credentials. resource server has to keep the client secret of the client handy to call this /introspect endpt. THis is very inconvenient. The design of it is really not from the perspective of a resource server, which uses this endpoint the most