When using the Org Authorization Server to issue an access token, local token validation process fails because Access Tokens issued by the Org Authorization Server are only intended to be used as authorization against Okta's own endpoints (for example, Userinfo), and it is not supported to secure a 3rd party server with these Access Tokens. For use cases where a third party resource needs to be protected via OAuth, use of a Custom Authorization Server is required.

• Okta Identity Engine (OIE)
• Okta Classic
• OAuth 2.0
• O​rg Authorization Server

Access Tokens from the Org Authorization Server are designed to be used and consumed by Okta only, and they can change and cause issues if decoded and verified locally, such as the typ header being changed when Okta started to use an externally published signing key, as outlined in the March 2024 Release. This is expected and accounted for by Okta's endpoints but should not be used otherwise.

Because Okta itself is the intended audience for these tokens, the aud parameter in these Access Tokens is the Okta org, for example, https://example.okta.com. An Access Token issued by the Okta Org Authorization Server is not safe to be used in an authorization use case, where the audience needs to be set to a resource server and custom scopes/proper access policies are required. 

How to resolve a token validation failure for an access token?

Access Tokens issued by the Org Authorization Server should only be used for Authentication use cases (Open ID Connect) and not Authorization use cases (OAuth). If the Authorization (OAuth) use case is needed, a Custom Authorization Server must be used instead (associated with the API Access Management feature), for which local token validation is supported.

Any integrations receiving Access Tokens from the Org Authorization should treat them as opaque. While it is technically possible to decode Access Tokens issued by the Org Authorization Server using a third-party decoder, the content of these tokens is subject to change at any time without notice, as outlined within our documentation for the Org Authorization Server. If the tokens need to be validated, use the Introspect endpoint to do so, as it will be up to date with any changes to Access Tokens issued by the Org Authorization Server and can successfully decode and validate securely. 

As Okta is the intended audience, Access Tokens issued by the Org Authorization Server can authorize Okta's APIs, notably the Userinfo Endpoint, Introspect Endpoint, and Management Endpoints.

Related References

• Va​lidate Access Tokens | Okta Developer
• A​uthorization Servers | Okta Developer
• When to Use the Org Authorization Server vs a Custom Authorization Server in Okta | Okta Support Center
• Open ID Connect Access Token | Okta Developer
• A​PI Access Management | Okta Developer
• Implement OAuth for Okta | Okta Developer  
• Implement OAuth for Okta with a Service App | Okta Developer