API rate limits by API token or OAuth 2.0 app
To protect the service for all customers, Okta APIs are subject to rate limits. These limits mitigate denial-of-service attacks and abusive actions such as rapidly updating configurations, aggressive polling and concurrency, or excessive API calls.
The Okta API rate limits are divided into the following categories: authentication/end user and management. Each category has APIs with rate limits that are enforced individually. The rate limits vary by service subscription (opens new window).
If any org-wide rate limit is exceeded, an HTTP 429 status code is returned. You can anticipate hitting the rate limit by checking the Okta rate limiting headers. Also, youâre sent an email notification when your org approaches its rate limit.
API rate limits by API token or OAuth 2.0 appNotes:
- In addition to the rate limit per API, Okta implements limits on concurrent requests, Okta-generated email messages, end user requests, and home page endpoints. These limits are described on the Additional limits page.
- DynamicScale rate limits apply to various endpoints across different APIs for customers that purchased this add-on. (The DynamicScale add-on service is only available to Customer Identity Solutions (CIS) customers.)
- Rate limits may be changed to protect customers. Okta provides warning of changes when possible.
- The type of cell your Okta org resides in (Preview or Production) doesn't affect the rate limit values. If you purchased dynamic scale or other rate limit increases for your org, these updates only apply to production orgs unless otherwise specified.
- You can expand the Okta rate limits upon request. To learn how, see Request exceptions and DynamicScale rate limits.
- Review the Rate limit best practices for further information on monitoring and managing your rate limits.
By default, Okta API tokens and OAuth 2.0 apps are configured to use 50% of an API endpoint's rate limit when they're created through the Admin Console. This configuration prevents a single API token or OAuth 2.0 app from exceeding the endpoint's rate limit in an org with multiple API tokens or apps.
To adjust the default rate limit capacity for API tokens or OAuth 2.0 apps from 50%, you can edit the percentage value in the Admin Console. See Set token rate limits (opens new window) for API tokens and Set the app rate limits (opens new window) for OAuth 2.0 apps. You can also use the Principal Rate Limits API (opens new window) to configure your API token or OAuth 2.0 app. Reducing the capacity percentage helps prevent a single API token or OAuth 2.0 app from consuming the entire endpoint rate, assists with investigating rate-limit violations, and reduces the likelihood of future violations.
The Admin Console tracks any rate-limit warnings or violations directly in a rate limit monitoring widget. By default, only the last hour of warnings or violations appear. You can also check for events within the last 24 hours or the last seven days from the dropdown menu. Selecting View at the top of the widget takes you to the Rate Limits dashboard for further investigation. If individual rate-limit violations appear in the widget, you can access affected API usage in the rate limits Dashboard by clicking the API link in the widget.
Burst rate limitsOkta provides rate limits for orgs based on their expected traffic. If your org experiences higher traffic than what is expected, this unplanned usage may have an impact on end users.
To help minimize this impact, Okta uses burst rate limits, which offer 5x the capacity of the base rate limit. With burst rate limits, Okta doesn't suspend use that's above the established rate, specifically for authentication and authorization flows (except in rare scenarios of reduced resources). However, if thereâs a sustained use above the purchased rate limit, Okta requires you to purchase an applicable offering that matches your use. With burst rate limits, Okta provides peace of mind by ensuring that, in most cases, an unplanned spike doesn't detrimentally affect the end user's experience.
Note: Burst rate limits don't apply when the concurrency rate limit threshold has been reached or exceeded for an org. While rare, burst rate limits may also not apply due to resource constraints at the time of the request.
In a scenario where orgs exceed a default rate limit, they receive a System Log warning event, a burst event, and then a violation event. For example, an org has a rate limit of 600 requests per minute on the /api/v1/authn endpoint. That org would receive a warning at 360 requests per minute (60% of 600). That org would get a burst notification when the endpoint hits 600 requests per minute. And then the violation event when it hits 3000 requests all in the same minute.
Also, burst rate limits typically apply on top of any rate limit increase that an org may have, such as DynamicScale. For example, the default limit on /api/v1/authn is 600 requests per minute. If an org is expecting traffic to require 6000 requests per minute, the org would purchase DynamicScale 10x. The burst rate limit in this scenario provides 5x coverage on top of the 6000 and ensures peace of mind for any unplanned spike in use.
On the rate limit dashboard, the trendline can now exceed 100% of the org's default rate limit (up to 5x the default with the buffer zone) as shown in the following example.
When a burst rate limit event occurs, the system.org.rate_limit.burst System Log event is triggered and an email notification is generated.
The email is sent to the same admin who received the system.org.warning and system.org.violation event emails.
Rate limit dashboard: The rate limit dashboard helps you understand the rate limit and current use of an API. The dashboard provides you with the ability to track the API's use and to notify you with alerts when the API is about to hit or has hit the rate limit. You can also use the multiple views of data use on the dashboard to investigate high usage or rate limit violations.
Rate limit best practices for further information on best practices to monitor and manage your rate limits.
Concurrent rate limits: To protect the service for all customers, Okta enforces concurrent rate limits, which is a limit on the number of simultaneous transactions. Concurrent rate limits are distinct from the org-wide, per-minute API rate limits, which measure the total number of transactions per minute. Transactions are typically short-lived. Even large bulk loads rarely use more than 10 simultaneous transactions at a time.
Client-based rate limits: To provide granular isolation, client-based rate limiting uses a combination of the client ID/IP address/device identifier for requests made to the OAuth 2.0 /authorize endpoint or the IP address/device identifier for requests made to the /login/login.htm endpoint. This framework isolates OAuth 2.0 clients that are generating unexpected traffic. It ensures that valid users and apps don't run into rate limit violations.
DynamicScale rate limits: If your needs exceed the default rate limits for the base product subscriptions (One App or Enterprise), the DynamicScale add-on service grants you higher limits for various endpoints across different APIs.
End user rate limits: Okta limits the number of requests from the Admin Console and End-User Dashboard to 40 requests per user per 10 seconds per endpoint. This rate limit protects users from each other and from other API requests in the system.
Home page endpoints and per-minute limits: These endpoints are used by the Okta home page for authentication and user sign-in and have org-wide rate limits.
Okta API endpoints and per-user limits: API endpoints that take username and password credentials, including the Authentication API and the OAuth 2.0 Resource Owner Password flow, have a per-username rate limit to prevent brute force attacks with the user's password. SMS and Call factor endpoints also have a per-username rate limit.
Okta-generated email rate limits: These rate limits vary by email type, for example, user password resets. Okta enforces rate limits on the number of Okta-generated email messages that are sent to customers and customer users.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4