OTP · primary factor
Enable OTP and enroll a supported OTP authenticator. Send a username (login_hint) and one-time code to the token endpoint.
urn:okta:params:oauth:grant-type:otpIDENTITY & ACCESS MANAGEMENT
OIDC PlaygroundLAB
Test your authentication. Understand every exchange.
Test here. Rotate credentials afterward. Use a test application. Rotate its client secret and revoke test tokens when you finish.
First, register your test application.
Copy the callback URLs and choose the grants to enable in your provider.
01 Choose your flow
9 availableMore flows · device, hybrid, legacy & token exchange
02 Connect your application
Not connectedNeed help finding your issuer URL?
An issuer identifies the authorization server. It is not your admin console, client ID, redirect URI or token endpoint.
Paste your Okta admin URL or organization URL. Candidate generation stays in this browser.
Where to confirm it in your provider
Universal rule: copy the exact issuer for the tenant, realm, policy, environment or user pool you intend to trust. Discovery must return the same issuer. A valid discovery document does not prove that your client, grants or access policies are configured.
Loads your provider’s OpenID configuration and endpoints.
openid identifies the userprofile basic detailsemail email claims
Requests an access token. The provider must authorize the subject, client, target and any actor relationship.
Endpoints & advanced settings ⌄
Only browser-accessible HTTPS endpoints are supported. Your provider must permit this origin with CORS for discovery, token, JWKS and UserInfo requests. Client secrets cannot be kept confidential in a browser. Other client authentication methods and form_post callbacks require a backend.
This is a browser test client. CORS restrictions can prevent a test even when the provider is working correctly.
♧ Credentials and tokens stay in this tab until sent to your configured provider. No analytics.
Behind the handshake
PKCE▣Your applicationIAM Buddy
⇄
♧Identity providerAuthentication server
Session explorer
Ready to test⇄
Your next “aha” starts here.
Connect your application and start a flow.
Every observable exchange will appear here.
Verify, don’t just decode.
After receiving an ID token, check its signature, issuer, audience, expiry and nonce.
Visibility: IAM Buddy shows requests it sends, returned callbacks, and responses the browser exposes. Provider login screens, internal processing, cookies and hidden network headers are outside its view.
SAML 2.0 service-provider lab
Hosted SSO validationConfigure an IdP application, run a real SSO login, and validate the trust decisions behind it.
01 Run a SAML SSO login
Hosted ACSUse the hosted IAM Buddy lab to get the exact ACS URL, SP Entity ID, recipient, destination, and metadata URL for your IdP. It receives the SAMLResponse after login and validates the XML signature, issuer, audience, time window, request correlation, RelayState, and replay protection.
Retest controls: choose Test login again to reuse the current IdP session, Reauthenticate at IdP to send
ForceAuthn="true", or Clear IAM Buddy test session to delete the stored test configuration and results.Manual assertion inspection
The inspector below remains available for assertion previews and troubleshooting when an IdP application cannot redirect to the hosted ACS.
02 Inspect a SAML assertion
No uploadPaste the raw <Assertion> XML from your IdP’s assertion preview. In Okta, use Preview the SAML Assertion while configuring the application. A complete raw XML or Base64 SAMLResponse is also accepted and provides additional response-level evidence.
Use unformatted XML without Markdown links or escape characters. Do not paste production assertions; they contain identity data and can remain usable until expiry.
Behind the SAML handshake
SP-initiated SSO- SP creates AuthnRequestEntity ID, ACS URL, request ID, issue time, destination, and optional requested authentication context.
- Browser carries the requestHTTP-Redirect or HTTP-POST binding sends SAMLRequest and optional RelayState to the IdP.
- IdP authenticates the userAssignment, sign-on policy, MFA, device, network, and session controls are evaluated.
- IdP posts SAMLResponseThe browser submits the signed response or assertion to the SP ACS URL.
- SP validates before session creationSignature, issuer, destination, recipient, audience, time window, InResponseTo, SubjectConfirmation, and replay protections must pass.
Assertion explorer
Waiting for dataNo SAML assertion yet.
Paste test data to see identity attributes, protocol fields, security checks, and troubleshooting guidance.
SAML failure checklist
TroubleshootingRegister IAM Buddy with your identity provider
Copy exact valuesCreate a dedicated test app. These addresses belong to IAM Buddy, the relying party that receives your provider’s responses. Your issuer and authorization endpoints belong to the identity provider.
Exact matching matters. Keep the scheme, path, trailing slash and query string exactly as shown. Do not register wildcards. Local preview and deployed URLs are different: use the values shown on the site where you will run the test.
Base URI, homepage and allowed web origin are provider-specific settings, not interchangeable redirect URIs. Register only fields your provider asks for. Front-channel logout URI and back-channel logout URI are not implemented here; leave them unset. An initiate-login URI can point to the base page, but it only opens the workspace and does not automatically start sign-in.
Interactive sign-in · recommended
PKCE- Choose an OIDC public browser / single-page application client for this browser-based tester.
- Enable Authorization Code. PKCE is protection for this grant, not a separate grant checkbox.
- Choose client authentication None and require PKCE S256 where available.
- Register the sign-in and sign-out redirect URIs above. Allow the web origin for supported browser endpoints.
- Assign your test user, allow the requested scopes and ensure the authorization-server policy permits this client.
- Copy the issuer URL and client ID into the playground. Use
openid profile emailto start.
Application acting on its own behalf
ServiceUse a separate service / API application with Client Credentials. Configure the authentication method required by the provider and API scopes approved for that client.
No browser sign-in or sign-out redirect URI is used by this grant. openid does not turn a service grant into a user sign-in.
This lab supports client_secret_basic and client_secret_post for disposable test secrets. Providers that require private_key_jwt or mTLS need a backend client, which this version does not implement.
Which grants should I enable?
Enable only what you testGrant names vary by provider. The categories below follow the settings you may see in Okta. An authorization server advertising a grant does not mean your application or its policy is allowed to use it.
Advanced grants are more sensitive. Keep them disabled unless your test specifically needs them. Test in a separate app and rotate its credentials afterward.
Okta: “Policy evaluation failed”
access_deniedThis means Okta received the authorization request, but no active authorization-server policy rule allowed its combination of client, grant, user, and scopes.
- Confirm IAM Buddy uses the intended issuer.
https://your-org.okta.comis the org authorization server;https://your-org.okta.com/oauth2/defaultis a custom authorization server. - For a custom server, open Security → API → Authorization Servers → your server → Access Policies.
- Confirm an active policy includes this OIDC application, then confirm an active rule permits the tested grant. PKCE requires Authorization Code.
- Confirm the rule permits the requested scopes. Start with
openid profile email; requestoffline_accessonly when testing refresh tokens. - For an interactive flow, assign the test user to the application and make sure the rule’s user or group condition matches that user.
- In the application’s General settings, confirm the same grant and the exact IAM Buddy sign-in redirect URI are registered.
Client credentials: use a service application and a rule whose user condition is No user. Do not use an interactive-user rule for that flow.
Login Failure Guide
IAM engineer checklistChoose what failed. IAM Buddy will build a prioritized validation path.
Provider-specific & backchannel setup · guidance only
Okta direct authentication · setup reference
Guidance onlyOTP, OOB, MFA OTP and MFA OOB are provider extensions, not the OIDC core browser flows. This version explains their configuration but does not execute their authentication or challenge requests.
Use an Identity Engine test org, an appropriate native test app, enrolled test authenticators and policies that permit the intended factors. Enable the relevant grant on both the client and the custom authorization server’s access-policy rule. Okta’s guide requires a super admin to enable these grants; do not enable all four by default.
OOB · primary factor
Enable OOB and the intended push, SMS or voice authenticator. Start at /primary-authenticate, then use the returned oob_code. Poll for push or supply a binding code for SMS/voice.
urn:okta:params:oauth:grant-type:oobMFA OTP · second factor
Enable MFA OTP and its initial grant. A first-factor response supplies an mfa_token; the next token request combines it with an OTP. A successful first factor alone does not complete authentication.
http://auth0.com/oauth/grant-type/mfa-otpMFA OOB · second factor
Enable MFA OOB and its initial grant. Use the returned mfa_token at /challenge, then redeem the oob_code. Respect the polling interval and any number-matching or binding-code challenge.
http://auth0.com/oauth/grant-type/mfa-oobThe HTTP-looking grant identifiers are literal parameter values, not endpoints. Actual requests must use HTTPS. Ordinary MFA during hosted PKCE sign-in does not require enabling these direct-auth grants.
CIBA · authenticate on another device
Guidance onlyClient-initiated backchannel authentication uses urn:openid:params:grant-type:ciba. It does not use a browser sign-in callback. Register a compatible confidential client, enable CIBA on the client and authorization-server policy, configure its backchannel authentication requirements and a supported delivery mode.
For Okta’s documented flow, configure the required signing keys and backchannel request settings, an eligible authenticator and test user. Ping/push delivery would require a secured notification receiver; IAM Buddy does not expose one. This version does not initiate or poll CIBA requests.
Okta CIBA configuration ↗Sign-out is a separate exchange
RP-initiated logoutAfter sign-in, use Test provider sign-out in the playground. IAM Buddy sends an id_token_hint, the registered post_logout_redirect_uri and a random state to the provider’s discovered end_session_endpoint. This can end your provider session and affect other applications using that session.
A matching return state confirms the callback belongs to this request; it does not prove every provider session ended. Signing out does not automatically revoke access or refresh tokens, and Clear session only removes this tab’s local test data.
OIDC RP-Initiated Logout specification ↗Inspect a token
Decoded locallyDecoding reveals data; it does not establish trust. Signed JWTs have three parts. Encrypted JWEs have five. Opaque tokens cannot be decoded.
Understand the result, then challenge the assumptions.
OAuth 2.0 delegates access. OpenID Connect adds authentication with an ID token and the openid scope. Client credentials represents an application, not a signed-in person.
What a successful test actually proves
1 / Exchange
Did the protocol complete?
Receiving tokens demonstrates that this request was accepted. Inspect the exact grant, redirect URI, scopes and provider response.
2 / Identity
Can this client trust this ID token?
Inspect signature, issuer, audience, lifetime and request binding. A decoded JWT has not passed these checks.
3 / Authorization
Does the API enforce the intended access?
Test this at your API. IAM Buddy does not prove resource permissions, role enforcement or tenant isolation.
A passing lab result describes one captured response. It is not a security certification for the application or identity provider.
Know which token belongs where
| Artifact | Consumer | Question to ask |
|---|---|---|
| Authorization code | Token endpoint | Is it one-time, short-lived and bound to this client, redirect URI and PKCE verifier? |
| ID token | The OIDC client | Does it identify the right subject for this issuer, client and authentication request? |
| Access token | The intended API | Does the resource server validate its token type, issuer, audience, expiry and granted permissions? |
| Refresh token | Token endpoint | What are its lifetime, rotation, reuse-detection and revocation policies? |
Architect review · beyond one successful login
Manual reviewUse these questions in your design review. IAM Buddy does not inspect these controls automatically.
Identity, tenant boundaries & assurance
Confirm the intended tenant and authorization server. Use the issuer and subject together as the identity key; a matching email alone is not proof of the same account. Decide which authentication assurance and freshness your application requires.
Inspect acr, amr and auth_time when present, then compare them with your provider’s policy and documented meanings. A visible MFA prompt alone is not a complete assurance-policy test.
Consent, scopes & least privilege
Compare the requested scopes with the returned scope and actual API behavior. Test with a user who has fewer permissions. Define which claims are essential, which can be absent and which come from UserInfo. Do not infer authorization from a display name, email or unvalidated custom role claim.
Keys, client type & credential lifecycle
Confirm whether your app can keep a secret. Keep confidential-client credentials on its backend in production. Define trusted issuers and signing algorithms independently of incoming tokens. Exercise signing-key rollover with your provider and check how clients recover from an unknown key ID.
Sessions, refresh tokens & sign-out
Review inactivity and absolute session limits, refresh-token rotation/reuse handling and token revocation. App logout, provider logout and token revocation are separate events. Confirm what happens when a user is disabled, loses a role or signs out on another device.
References: OIDC Core · OAuth Security BCP. Provider-specific assurance and access policies must be checked against your own provider documentation.
Negative tests worth running
Not automatically executedUse an isolated test app and a controlled test harness. Record the rejection and its source; a client rejecting data is different from a provider enforcing its configuration.
| Change one condition | Expected result | Where to verify |
|---|---|---|
| Use an unregistered redirect URI | Provider rejects the request without sending tokens to that URI. | Provider / test harness |
| Redeem a code twice, or use an incorrect PKCE verifier | Token endpoint rejects the invalid redemption. | Provider / test harness |
| Alter state, nonce, audience or signature; present an expired ID token | Client refuses to establish a trusted identity. | Your application’s callback and token-validation tests |
| Call an API without the required permission or with another tenant’s token | API rejects access. | Resource server / API tests |
| Reuse a replaced refresh token or revoke the grant | Behavior matches your documented rotation and revocation policy. | Provider and application tests |
These are review scenarios, not results from your current session. This lab performs the validation checks shown in its session explorer; it does not run a provider penetration test.
Flow-by-flow reference · all 9 test flows
Scopes request access. Claims describe facts.
openid requests OIDC authentication. profile, email, address, and phone request standard claim groups; actual release depends on provider policy and consent. offline_access requests offline access and typically requires consent. An ID token does not necessarily contain every requested claim: use UserInfo where supported.
iss identifies the issuer; sub identifies the subject within that issuer; aud identifies the intended recipient. API-specific scopes and custom claims have meanings defined by your provider.
Practical setup
- Create a separate test application in your provider.
- Enable the grant you want to test and register the exact redirect URI shown in the playground.
- Allow this site’s origin for browser requests where your provider supports CORS.
- Discover endpoints, enter the client ID and scopes, then start a flow.
- Inspect the exchanges, verify the ID token and review UserInfo.
- Rotate client credentials, revoke test tokens at your provider, and clear the session.
Scope of this first component
Core OIDC code, implicit and hybrid flows; PKCE; OAuth password, client credentials, device, refresh and token-exchange grants, plus RP-initiated logout. CIBA and Okta direct-auth grants have setup guidance but are not executable in this version. PAR/JAR, DPoP, mTLS and signed request objects are not implemented. Verification supports RS256, ES256 and PS256, not encrypted ID tokens.
References: RFC 6749 · OIDC Core · PKCE / RFC 7636 · Device grant / RFC 8628 · Security BCP / RFC 9700