Introspection Endpoint should work for tokens issued by different client?

Questions
1

In the Token Introspection Endpoint documentation (here) we indicate that when “The token was issued to a different client than is making this request”, it should be “considered an ‘inactive’ token”.

However, I create two clients (for instance, ClientCredentialsONE and ClientCredentialsTWO), and I can introspect the tokens issued by the first providing the credentials of the second client just fine.

By the way, the official Introspection Endpoint specs (RFC 7662) doesn’t indicate anything regarding this, but it seems on practice most providers (I’ve tried with Curity, Azure AD and Keycloak) allow introspecting tokens issued to a different client, just as Okta does in practice, so it might be just a matter of updating the Token Introspection Endpoint documentation.

2

Hello,
I can look into this. Our documentation for this endpoint can be found here. In the case of passing an Authorization header to the call to introspect, it looks like Okta is just checking if it is a valid client_id/secret combo for the Org, not if the tokens client_id matches. The OAuth page you linked to may have meant to state that the introspection endpoint needs to be called on the same authorization server that minted the token. For instance if you have two custom authorization servers in your Org, mint the token with authorization server A, but call introspection on B, it would come back as inactive.