API Access Management
This is an Early Access feature. To enable it, please contact Okta Support.
API Access Management allows you to build custom authorization servers in Okta which can be used to protect your own API endpoints.
An authorization server defines your security boundary, for example “staging” or “production.” Within each authorization server you can define your own OAuth scopes, claims, and access policies. This allows your apps and your APIs to anchor to a central authorization point and leverage the rich identity features of Okta, such as Universal Directory for transforming attributes, adaptive MFA for end-users, analytics, and system log, and extend it out to the API economy.
At its core, an authorization server is simply an OAuth 2.0 token minting engine. Each authorization server has a unique issuer URI and its own signing key for tokens in order to keep proper boundary between security domains. The authorization server also acts as an OpenID Connect Provider, which means you can request ID tokens in addition to access tokens from the authorization server endpoints.
How do I choose an authorization service?
How do you know if you need to use Okta’s authorization server instead of the authorization service that is built in to your Okta app?
How do I set up an authorization server?
To manage authorization between clients and Okta,
It doesn’t matter which task you do first, but the client app must recognize the scope names and be expecting the claims as defined in the authorization server.
To create and configure an authorization server, follow these steps:
Create the Authorization Server
When complete, your authorization server Settings tab displays the information that you provided and allows you to edit it.
Scopes represent high-level operations that can be performed on your API endpoints. These are coded into applications, which then ask for them from the authorization server, and the access policy decides which ones to grant and which ones to deny.
If you need scopes in addition to the reserved scopes provided, create them now.
These scopes are referenced by the Claims dialog.
Note: If you create an app that uses the User Consent for OAuth 2.0 and OpenID Connect Flows feature, set the User Consent to Yes for the scope, as shown below.
Tokens contain claims that are statements about the subject or another subject, for example name, role, or email address.
ID Token claims are dynamic. By default, the Authorization Server does not include them in the ID Token when requested with an Access Token or authorization code. To use this default, select When Requested for Include in token type.
To force the Authorization server to always put an ID Token claim into the ID Token, select Always for Include in token type.
Note: If the claim is not included, the client must use an Access Token to get the claims from the UserInfo endpoint.
Create ID Token claims for OpenID Connect, or Access Tokens for OAuth 2.0:
While in the Claims list, you can:
While in the Access Policy list, you can:
Polices are evaluated in priority order, as are the rules in a policy. The first policy and rule that matches the client request is applied and no further rule or policy processing occurs.
Rules control the mapping of client, user, and custom scope. For example, you can specify
a rule for an access policy so that if the user is assigned to a client, then custom scope
While in the Rules list for an access policy, you can:
For each combination of authorization serve, scopes and claims, client, and user, issue an API call and check that the contents of the ID Token or Access Token are as expected.
Token preview for OpenID Connect ID or OAuth 2.0 access tokens
Configuring an application or integration to use OpenID Connect ID tokens or Oauth 2.0 access tokens can take a lot of trial-and-error. Okta has made it easier to choose configuration settings and see the resulting tokens in the Token Preview tab of the Authorization Server page, as shown below.
Add values on the left side to see how they would affect the token on the right. All the fields are selection boxes except User. For User, type in the first few letters to see a choice of user names.
You can try out different combinations of values, and see the resulting tokens (or error messages). Once you've got the right combination, it's easy to configure your authorization server and other components.
Delete an Authorization Server
To delete an authorization server, click the Actions button to the right of the authorization server name, and the click Delete.
Use the search field to search on the exact name of the authorization server or Resource URI.
You can set an authorization server to manually rotate keys. Keys are rotated automatically by default.
Important: Automatic key rotation is more secure than manual key rotation. Use manual key rotation only if you can't use automatic key rotation
To change an authorization server configuration: