Org authorization server: discovery, keys, authorize, token, userinfo, introspect, revoke.
Category IdentityStack Okta (hosted)Jobs 31
Load tests an Okta org authorization server: discovery, keys, authorize, token, userinfo, introspect and revoke. Okta enforces rate limits per org, so use a test org and expect 429 responses at higher rates.
It holds 31 ready-made jobs: 24 single scenarios and an enterprise test plan of 7 stages to run in order, 7 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include OIDC discovery document, discovery document (cache bypass), JSON web key set, authorization endpoint (login page or redirect) and silent authentication (prompt=none).
url, clientId and redirectUri to point at your own Okta system, ideally a staging copy.urlclientIdclientSecretredirectUriscopetokenauthServerThis is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Fetched by every relying party at start-up and on a timer. Cheap, but often served uncached.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Forces the origin to build the document. Shows the cost behind a CDN or cache.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Every API validating tokens locally refreshes keys from here, and a key rotation causes a thundering herd of fetches.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Start of every browser login. Redirects are NOT followed, so this measures the provider itself, not the login page it forwards to.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. What SPAs do in a hidden iframe to renew a session. With no session it must answer with a login_required redirect, quickly, and without rendering a page.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Error path: an unregistered client_id must be refused cheaply. If it costs as much as a real login, attackers can load you for free.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Must be rejected with an error page, never redirected (open-redirect check): a 302 to the bad URI would be a vulnerability, so only 4xx and the error page count as success.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Machine-to-machine tokens. Signing a JWT is CPU bound, so this is where most providers saturate first. Creates tokens and sessions: staging only.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Same grant, client authenticated with an Authorization: Basic header. Replace the header value with base64(clientId:secret) when running from the UI.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Failed client authentication. Should be fast, rate limited and logged. Keep the rate low: some providers lock the client after repeated failures.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. A bogus code at the token endpoint (invalid_grant). Replayed or guessed codes land here, so it must stay cheap.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Token renewal, the most frequent token call in a long-lived app. If refresh tokens ROTATE, only the first request succeeds and the rest fail with invalid_grant: use a client without rotation.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Swaps a token for another (service-to-service delegation). Not every provider supports it; a 400 unsupported_grant_type is counted as an error.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Browser apps send an OPTIONS before calling the token endpoint. It must be answered at the edge, not by the identity code.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Ramps client-credentials requests up to find the rate where latency or errors climb: your token-issuing capacity. Staging only.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Opaque-token APIs call this on every request, so its latency is added to your whole API. Needs a valid token.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Probing with garbage tokens must return active=false quickly. Expensive here means a cheap amplification attack.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Logout and security flows. Revoking an unknown token must still return 200 (RFC 7009).
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Called by apps after login and by gateways per request. Needs a valid token.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Rejection path: should be a fast 401.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Unauthenticated requests: also a fast 401, and a good WAF/rate-limit canary.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Steady load for ten minutes: finds cache expiry, connection and memory problems in token validation.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. Starts a TV or CLI login. Creates a pending device code per request, so it also tests the cleanup of abandoned ones. Staging only.
This is a hosted identity service: check the vendor's load-testing policy and your tenant's rate limits before running, keep the rate low, and expect 429s. RP-initiated logout without a session: shows a confirmation page or redirects. Redirects are not followed.
Run in order: smoke, baseline, load, stress, spike, soak, breakpoint and failover window, each with pass/fail targets.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: authorization endpoint (login page or redirect). Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: authorization endpoint (login page or redirect). Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: authorization endpoint (login page or redirect). Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: authorization endpoint (login page or redirect). Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
Step 8 of 10, shortened for a hosted service. Steady load for 30 minutes to catch token or session expiry problems and slow decay on your side. Reference request: authorization endpoint (login page or redirect). Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
An API gateway that introspects opaque tokens adds one introspection call to every business request, so the identity provider carries the whole API's traffic. Three times normal for 10 minutes. Reference request: token introspection. Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
Apps call userinfo after login and on every page load. Three times normal for 10 minutes. Reference request: userinfo with a valid token. Hosted identity service: this stays well below the vendor's rate limits; check their load-testing policy first.
The Okta template has 31 jobs: 24 single scenarios and an enterprise test plan of 7 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include OIDC discovery document, discovery document (cache bypass), JSON web key set and authorization endpoint (login page or redirect). 7 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
Open the template in BLASTA and set url, clientId and redirectUri, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new okta with your address.
Of the 31 jobs, 24 are read-only, 1 write data and 6 change state. Run the writing and state-changing jobs against a staging system, never against production data. Only test systems you own or have permission to test.
Welcome back. Sign in to run and review load tests.
Send the confirmation email again
Just looking? Try a quick test without an account
Point BLASTA at something you own, choose how hard to hit it, and press Start test. Results stream in live.
Queries are read-only unless Allow writes is on.
Multi-statement input and writable CTEs (WITH d AS (DELETE…)) are always refused.
For MQTT, LDAP, AMQP and other binary protocols. The templates fill this in for you.
The address accepts host:port or tcp://host:port.
Leave this empty to only test the connection handshake.
No results yet
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Ready-made jobs for common systems. Search by system, protocol or what you want to test (wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.
You are browsing as a visitor: you can read every job here. Sign in or create an account to use them.
Fill in your system's address. The jobs below update as you type.
Your tests. Open one to see it the way it looked live, with its charts, load settings and server usage.
| When | Job | Target | Requests | Avg req/s | p95 | Errors | CPU avg | RAM avg | Result |
|---|
Charts were not recorded for this run (it was saved by an older version).