API

Use the API page to manage and create all Okta API tokens, and to add Origin URLs.

Tokens

API tokens are used to authenticate requests to the Okta API just like HTTP cookies authenticate requests to the Okta Application with your browser. An API token is issued for a specific user and all requests with the token act on behalf of the user. API tokens are secrets and should be treated like passwords.

API token are generated with the permissions of the user that created the token. If a user’s permissions changes, then so does that of the token. Okta recommends generating API tokens from a service account with permissions that do not change.

API tokens are valid for 30 days and automatically renew every time they are used with an API request. When a token has been inactive for more than 30 days it is revoked and cannot be used again. Tokens are also only valid if the user who created the token is also active. Tokens issued by deactivated usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. are rejected. If the user account is reactivated, the API token is accepted with no other action required.

Okta Agents are also issued API tokens during installation which they use to access your Okta organization. While these tokens are similar to the standard API token, they are managed by Okta.

Use the API Token page to manage all Okta API tokens. AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. tokens are usually managed when you activate, deactivate, or reactivate an agent.

Agent tokens are displayed on this page for your review, and to highlight any security issues that might arise with them. Most agents use a token. The token setup is usually handled automatically when you activate or reactivate an agent. This list of tokens contains Okta token usage information for your organization.

There are five actions available to manage tokens.

Trusted Origins tab

All cross-origin web requests and redirects from Okta to your organization’s websites must be explicitly whitelisted. Use the Trusted Origins tab to grant access to websites that you control and trust to access your Okta orgAn abbreviation of organization, but can also be thought of as a company. A company that uses Okta as their SSO portal is generally referred to as an org. As an administrator, you decide how Okta should be displayed and/or integrated with your org. through the Okta API. An Origin is a security-based concept that combines the URI scheme, hostname, and port number of a page.

To access the Trusted Origins page, do the following:

  1. Click Trusted Origins.
  2. Click the Add Origin button. The Add Origin screen appears.
  3. Enter the Name and Origin URL fields for the page.
  4. Choose the Origin type from the following list.
    • CORS – Cross-Origin Resource Sharing (CORS) allows JavaScript hosted on your websites to make an XMLHttpRequest to the Okta API using the Okta session cookie.
    • Redirect – Allows for browser redirection to your org's trusted websites after signing in or out.

Rate Limiting

API endpoint throttling limits have been created to protect the Okta service (in Production and Preview tenants) from load spikes or service interruptions caused by submitted requests (whether unintentional or as a Denial of Service attack). This strategy has been adopted across the industry in many SaaS applications and platforms to maintain consistent service levels for customers. Requests that hit the rate limits return a "429 Too Many Requests" HTTP status code.

Public applications are aggressively rate-limited to prevent abuse and require primary authentication to be successfully completed before releasing any metadata about a user. For more information, see Okta Authentication API.

Concurrent Rate Limits

In order to protect the service for all customers, Okta enforces concurrent rate limits. These limits are distinct from the org-wide, per minute API rate limits.

For concurrent rate limits, traffic is measured in three different areas: agent traffic, Microsoft Office 365 traffic, and all other traffic, including API requests. Counts in one area are not included in counts for the other two areas.

  • For agent traffic, Okta measured each org’s traffic and set the limit at above the highest usage in the last four weeks.
  • For Microsoft Office 365 traffic, the limit is 75 concurrent transactions per org.
  • For all other traffic including API requests, the limit is 75 concurrent transactions per org.

The first request to exceed the concurrent limit returns an HTTP 429 error, and the first error every sixty seconds is written to the log. Reporting concurrent rate limits once a minute keeps log volume manageable.

Default Rate Limits

API endpoint throttling limits have been created to protect the Okta service (in Production and Preview tenants) from load spikes or service interruptions caused by submitted requests, whether unintentional or as a Denial of Service attack. This strategy has been adopted across the industry in many SaaS applications and platforms to maintain consistent service levels for customers. Requests that hit the rate limits return a 429 Too Many Requests HTTP status code.

Public applications are aggressively rate-limited to prevent abuse and require primary authentication to be successfully completed before releasing any metadata about a user. For detailed information about Okta API rate limits, including working with headers that report the limit in each API response, see https://developer.okta.com/docs/api/getting_started/design_principles#rate-limiting

Other default rate limits are listed by endpoint in the following table. Okta may raise or lower the limits without notice in the process of maintaining the service.

Rate Limited URI

Requests per minute

'/app/{app}/{key}/sso/saml'

750

'/app/office365/{key}/sso/wsfed/active'

2,000

'/appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in./office365/{key}/ssoAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones./wsfed/passive'

250

'/app/template_saml_2_0/{key}/sso/saml'

2,500

'/login/do-login'

200

'/login/login.htm'

850

'/login/sso_iwa_auth'

500

Requesting Exceptions

While endpoint throttling is enforced uniformly for all Okta customers, there are occasionally scenarios where a customer request for a temporary rate limit increase can be accommodated. An example would be an initial deployment scenario where a very large number of users and groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. are being imported to Okta. In such a scenario, the customer can seek to make arrangements for a temporary exception.

Requests must be received 10 business days prior to the time frame during which an increase is required. To request an exception, open a case with Okta Support and provide the following details:

  1. Org Name
  2. Endpoints and Rates
    • Which URI's need to have their limits increased
    • How much of an increase is required?
  3. Start date and time
  4. End date and time
  5. Business Justification
    • Please provide details on your organizations requirements that drive the request.

Okta reserves the right to rate limit other functionality to prevent abuse, spam, denial-of-service attacks, or other security issues. Where possible Okta will offer a descriptive error code.