v2.0 endpoints for one tenant: discovery, keys, authorize, token, device code.
Category IdentityStack Microsoft identity platformJobs 22
Load tests the Microsoft Entra ID (Azure AD) v2.0 endpoints for one tenant: discovery, signing keys, the authorize endpoint, token requests (client credentials, refresh and error cases) and device code. Microsoft throttles heavy traffic, so use a dedicated tenant and keep rates modest.
It holds 22 ready-made jobs: 17 single scenarios and an enterprise test plan of 5 stages to run in order, 5 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, redirectUri and tenant to point at your own Microsoft Entra ID system, ideally a staging copy.urlclientIdclientSecretredirectUriscopetokentenantThis 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. 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.
The Microsoft Entra ID template has 22 jobs: 17 single scenarios and an enterprise test plan of 5 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). 5 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, redirectUri and tenant, 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 entra-id with your address.
Of the 22 jobs, 16 are read-only, 0 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).