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?