<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
How to Review System Logs for OpenID Connect Applications to Verify if They Use a Custom Authorization Server
Okta Classic Engine
Okta Identity Engine
API Access Management
Overview

As the API Access Management license is usage-based (Monthly Average Users for user-based flows, tokens issued for Machine-to-Machine flows), it is possible to query the org's System Log to gather information about what applications are using a Custom Authorization Server . This information can then be used to adjust the Access Policies to ensure that only the desired applications can use a custom authorization Server.

NOTE: The System Log entries are retained for 90 days (more information can be found in Okta’s Customer Data Retention Policy), so you may be unable to find recent token grant events for any applications that have not been used within the last 90 days. In this case, please work with the internal application owners to confirm their configuration/needs.

If there are any questions about the contract and licensing, please contact the Account Manager for details about the Org/Account.
 

Applies To
  • API Access Management
  • Custom OpenID Connect application
Cause

The below queries are designed to return token grant events for tokens issued by a Custom Authorization Server. Any tokens that were granted by the built-in Org Authorization Server will not be included in the output of these queries as they do not utilize the API Access Management license.

Machine-to-Machine (M2M)

eventType eq "app.oauth2.as.token.grant.access_token" and debugContext.debugData.grantType eq "client_credentials"
In the events returned, find the name of the OpenID Connect application that requested this token in actor.displayName, the application ID in actor.id, the name of Authorization Server that granted the token in
debugContext.debugData.authorizationServerName and the ID of the server in debugContext.debugData.authorizationServer.

M2M

User-based flows (MAU)

(eventType eq "app.oauth2.as.authorize.implicit.access_token" OR eventType eq "app.oauth2.as.authorize.implicit.id_token" OR eventType eq "app.oauth2.as.token.grant" OR eventType eq "app.oauth2.as.token.grant.access_token" OR eventType eq "app.oauth2.as.token.grant.id_token" OR eventType eq "app.oauth2.as.token.grant.refresh_token") AND debugContext.debugData.grantType ne "client_credentials"

In the events returned, find the name of the OpenID Connect application that requested this token in actor.displayName, the application ID in actor.id, the name of Authorization Server that granted the token in debugContext.debugData.authorizationServerName, the ID of the server in debugContext.debugData.authorizationServer, and the user granted the token in target.id

User granted token
 
Solution

Once identified which Clients/Applications will be used in the Custom Authorization Server, update the Access Policies accordingly. When updating/creating the Access Policies for all Custom Authorization Servers, ensure that the policies are configured so that only the appropriate application(s) can request tokens.

For example, if there is a single custom authorization server that should only be used by a single Test App client, then the policy should be assigned to only the Test App.

Test App Authorization Server - Access Policies
 

Related References

Loading
How to Review System Logs for OpenID Connect Applications to Verify if They Use a Custom Authorization Server