How To: Use the OIDC Multi-Flow Tester Tool

Version Affected: All

 

Overview

The OIDC Multi-Flow Tester is a browser-based internal tool that stands in for a real OIDC application/Service Provider (SP), for testing OIDC configuration against a realm without needing a real registered application. It can authenticate against a realm to retrieve Identity, Access, and Refresh tokens; decode and validate those tokens; and test a realm’s Introspection, UserInfo, and Revocation endpoints. It is for Test/Development use only — do not point it at a production realm.

For background on what each flow actually does and when it is used, see How To: OAuth 2.0 / OpenID Connect Flows: Overview.

The Tester can walk through four of these flows directly. Pick whichever matches what you’re testing:

• Method 1 — Authorization Code: the standard interactive, browser-redirect flow. Use this for most realm/application login testing, including PKCE.
• Method 2 — Client Credentials: a machine-to-machine flow with no user involved. Use this to test a realm configured for server-to-server API access via a custom scope.
• Method 3 — Password Grant: the client collects the end user’s username and password directly instead of redirecting to the IdP. Use this to test a legacy trusted first-party integration.
• Method 4 — Implicit (legacy): a deprecated redirect-based flow that returns tokens directly in the browser URL, with no Client Secret. Use this only to validate an existing legacy integration still configured for it.
   

In this article

• Method 1: Test the Authorization Code Flow
• Method 2: Test the Client Credentials Flow
• Method 3: Test the Password Grant Flow
• Method 4: Test the Implicit (Legacy) Flow

Method 1: Test the Authorization Code Flow

This is the flow most SecureAuth Identity Platform realms use for a standard interactive login, and the only one of the four with built-in PKCE support.

1. Open the OIDC Multi-Flow Tester and click I Understand – Continue to accept the notice (only needed the first time in a browser session).
2. Select Authorization Code from the Flow dropdown — this is the default selection.
3. Enter the realm’s Authorization URL. The Tester uses it to automatically populate the OpenID Configuration URL (discovery endpoint), Token Endpoint URL, and Redirect URI fields — this auto-population is geared toward SecureAuth Identity Platform OIDC Realms specifically. If the discovery or token endpoints need to differ from what was auto-populated, they can be adjusted manually in their respective fields.
4. Confirm the auto-populated Redirect URI (defaults to https://helix.identity.secureauth.com/OIDCTester/) is added to the realm’s Allowed Redirect URIs before continuing — the flow will fail otherwise.
5. Enter the realm’s Client ID, Client Secret, and Scopes (defaults to openid profile email), and check Enable PKCE if the realm requires it.
6. Optionally set State or Nonce values to test how the realm handles them, or add extra parameters under Additional Parameters.
7. Click Start Authentication.
8. Review the results under Results & Tokens: the returned Auth Code, Access Token, ID Token, and Refresh Token each have their own Copy and Decode/Validate actions (the Refresh Token also has Use Refresh Token), and the Introspection, UserInfo, and Revoke Token buttons test those endpoints against the tokens just retrieved.

Method 2: Test the Client Credentials Flow

Use this to test a realm or client configured for machine-to-machine access with no interactive user login.

1. Select Client Credentials from the Flow dropdown.
2. Enter the realm’s OpenID Configuration URL and click ► Show OIDC Configuration to auto-populate the Token Endpoint URL — or enter the Token Endpoint URL directly. This flow has no Authorization URL or Redirect URI field, since no browser redirect is involved.
3. Enter the realm’s Client ID and Client Secret.
4. Enter the custom Scopes configured for this client (for example, api.read) — this flow requires a custom scope; the standard openid profile email scopes used by the other flows don’t apply here.
5. Click Get Access Token.
6. Review the returned Access Token under its own Copy and Decode/Validate Access Token actions. This flow doesn’t return an Auth Code, ID Token, or Refresh Token.

Method 3: Test the Password Grant Flow

Use this to test a legacy trusted first-party client that collects the end user’s username and password directly, rather than redirecting to the IdP.

1. Select Password Grant from the Flow dropdown.
2. Enter the realm’s OpenID Configuration URL and click ► Show OIDC Configuration to auto-populate the Token Endpoint URL — or enter the Token Endpoint URL directly.
3. Enter the realm’s Client ID, Client Secret, and Scopes (defaults to openid profile email).
4. Enter the test user’s Username and Password.
5. Click Get Access Token(s).
6. Review the returned Access Token, ID Token, and Refresh Token (each with their own Copy and Decode/Validate actions; the Refresh Token also has Use Refresh Token) — which of these come back depends on the scopes granted and the realm’s Refresh Token / consent storage configuration.

Method 4: Test the Implicit (Legacy) Flow

This is a deprecated, redirect-based flow that returns tokens directly in the browser URL and has no Client Secret. The Tester itself warns that Implicit does not support PKCE and exposes tokens in the URL fragment — use it only to validate an existing legacy integration still configured for it, not for new testing.

1. Select Implicit (legacy) from the Flow dropdown.
2. Enter the realm’s Authorization URL; the Tester automatically populates the OpenID Configuration URL (discovery endpoint) and Redirect URI fields from it, the same as for the Authorization Code flow. This flow never calls a token endpoint directly, so there is no Token Endpoint URL field.
3. Confirm the auto-populated Redirect URI is added to the realm’s Allowed Redirect URIs before continuing.
4. Enter the realm’s Client ID and Scopes (defaults to openid profile email) — there is no Client Secret field for this flow.
5. Optionally add State, Nonce, or other values under Additional Parameters — this flow doesn’t have the dedicated State/Nonce fields the Authorization Code flow does.
6. Click Start Authentication.
7. Review the returned Access Token and ID Token under Results & Tokens. This flow doesn’t return an Auth Code or Refresh Token.

The Tester doesn’t include a dedicated option for the Hybrid flow. To test Hybrid, or to see the underlying HTTP-level request/response details behind any of the flows above, see How To: Test OAuth / OpenID Connect Flows.

Special Considerations

For Test/Development environments only — this tool is not meant to be pointed at a production realm. All input (URLs, Client ID/Secret, tokens) is kept in the browser’s own local storage and is never sent anywhere other than the realm you configure it against.

The Password Grant panel also shows an Enable PKCE checkbox — PKCE doesn’t apply to this grant type (there’s no authorization redirect to protect), so it can be left unchecked.


 

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.