Okta Token Introspection With Unassigned Authorization Server Clients
Last Updated:
Overview
A client can perform token introspection in Okta even with a disallowed grant type and clients not specified in the Access Policy. A client not assigned to the authorization server can still introspect an access token granted to a client assigned to the server, provided the client authenticates properly. Common questions regarding OAuth 2.0 token introspection include system logging, cross-client validation, and access policy requirements for dedicated introspection clients.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- API Access Management
- OAuth 2.0
- Token Introspection
- Authorization Server
Solution
A client not assigned to the authorization server can still introspect an access token granted to a client assigned to it. The authorization server's introspection still requires some form of client authentication.
Are token validation events via the /introspect endpoint recorded in Okta System Logs?
Token validation performed through the /introspect endpoint does not generate a System Log entry in Okta.
NOTE: If troubleshooting configuration issues requires investigating a specific time window, contact Okta Support. Okta Support may have visibility into these events through internal log systems.
Cross-client token validation capabilities depend on the client type.
According to Section 4 of Request for Comments (RFC) 7662, an authorization server must require authentication of protected resources that need to access the introspection endpoint. This intentional design eliminates the need to share credentials between the client that requests tokens and the resource server that receives and validates them.
The ability to introspect tokens across clients depends on the following client types.
- Confidential Clients: Clients with a client secret can introspect tokens issued to any application within the same Authorization Server.
- Public Clients: Clients with no secret can only introspect tokens explicitly issued to themselves. Public clients are not authorized to validate tokens issued to other applications.
Does a client set up solely to act as an introspect endpoint need an access policy?
Defining an access policy for that client is unnecessary. Token introspection does not depend on access policy assignment. However, the client must still authenticate with the authorization server to use the endpoint.
