OpenID Connect Playground overwrites custom client credentials with site-default values during the authorization code exchange

Get Help
1

I am experiencing what appears to be a regression in the OpenID Connect Playground at https://www.openidconnect.net/.

Use case

I use the playground to demonstrate an OIDC authorization code flow between Cisco Duo Single Sign-On and a test OIDC application. This workflow worked successfully in the past, but it began failing several months ago.

Steps to reproduce

  1. Open https://www.openidconnect.net/.
  2. Select Configuration.
  3. Select Custom as the Server Template.
  4. Enter a valid OIDC discovery document URL.
  5. Select Use Discovery Document and verify that the authorization, token, and JWKS endpoints are populated correctly.
  6. Enter the client ID and client secret associated with the OIDC application.
  7. Save the configuration and select Start.
  8. Authenticate successfully through the identity provider.
  9. Allow the identity provider to redirect the browser back to the playground.
  10. Continue to the Exchange Code for Token step.

Expected result

The playground should use the client ID and client secret entered before the authorization redirect when it sends the authorization code to the token endpoint.

Actual result

At the token-exchange step, the playground replaces the client ID and client secret I entered with a different pair of credentials. The token request consequently fails with:

“The Exchange Could Not Be Performed.”

If I manually edit the token request and restore the correct client ID and client secret, the exchange succeeds. This indicates that the discovery document, authorization request, identity-provider authentication, callback, authorization code, and token endpoint are all functioning correctly. The failure occurs because the playground uses the wrong client credentials when constructing the token request.

Troubleshooting performed

I initially suspected local storage, browser autofill, or an extension, so I performed the following troubleshooting:

  • Selected the playground’s Clear LocalStorage option.
  • Cleared cookies, local storage, session storage, IndexedDB, cache storage, and service-worker data through Chrome Developer Tools.
  • Completely quit and relaunched Chrome.
  • Repeated the test in an Incognito window.
  • Tested different server templates, including Custom, Auth0, and Google.
  • Tested from a separate computer that had never previously visited the playground.

Clearing the browser data successfully removed my previously stored Duo endpoint values. However, the same site-default client ID and client secret continued to appear for every server template, including on the previously unused computer.

For security reasons, I have omitted the complete values from this post, but I can provide the non-sensitive identifying details privately if needed.

Why this appears to be a playground regression

The behavior reproduces across clean browser sessions and separate computers. The client ID and client secret therefore appear to be supplied by the playground itself rather than by local browser storage, autofill, or the OIDC discovery document.

The discovery document cannot be the source because OIDC discovery metadata does not provide client-specific credentials. In addition, the same default credentials appear regardless of which server template is selected.

The apparent sequence is:

  1. The user enters valid custom client credentials.
  2. The playground uses the configuration to start the authorization flow.
  3. The identity provider authenticates the user and returns an authorization code.
  4. The playground reloads or reconstructs its configuration after the callback.
  5. Site-default credentials overwrite the custom credentials.
  6. The token request is sent using those default credentials.
  7. The identity provider rejects the exchange because the authorization code was issued to a different client.

Could someone confirm whether this is a known issue or recent regression? Is there a supported workaround that will preserve custom client credentials through the callback and token-exchange steps?

Environment

  • Playground: https://www.openidconnect.net/
  • Browser: Google Chrome 153.0.8010.53
  • Operating system: macOS 27.0
  • Identity provider: Cisco Duo Single Sign-On
  • Flow: OIDC authorization code flow
  • Most recently reproduced: September 21, 2026
3

Hi @kbanas

Welcome to the Auth0 Community!

You are reporting a regression in the OpenID Connect Playground (openidconnect.net) where custom client credentials are being replaced with site-default credentials during the token-exchange step of an OIDC authorization code flow. You have performed thorough troubleshooting across multiple browsers and computers, and the issue reproduces consistently. You are asking whether this is a known issue and whether there is a workaround.

[Root Cause]

  1. Server-Side Session / State Reconstruction Failure:
    The playground relies on a backend session (or temporary cached state keyed by the authorization state parameter) to retain transient parameters—such as the custom client_id and client_secret—across the browser redirect to and from the IdP.

  2. Default Fallback Overwrite:
    When the identity provider redirects back to https://openidconnect.net/callback, the playground reconstructs its step-by-step UI state. If the session cookie is dropped (often due to modern cross-site cookie restrictions/Partitioned Cookies/SameSite handling across top-level redirects) or if the backend fails to re-hydrate the custom configuration from the redirect state, the playground falls back to its server environment defaults (the default Auth0 demo tenant credentials).

  3. Mismatched Client in Token Exchange:
    Because the authorization code was issued specifically for your Cisco Duo application’s client_id, the authorization server rejects the token request when it arrives with the playground’s default client_id and client_secret, generating the error:

    “The Exchange Could Not Be Performed.”

[Recommended Workarounds]

Since the root issue lies in how the hosted service persists state across redirects, the following workarounds avoid the regression:

Option 1: In-Place Credential Restoration (Quickest)

As you discovered, manually restoring your custom client_id and client_secret in the UI at the Exchange Code for Token step before sending the request allows the token exchange to complete.

Option 2: Alternative OIDC Debugger Tools

For a tool that maintains client state purely in the browser without backend state drops:

  • OIDC Debugger (oidcdebugger.com): Stores configuration directly in client-side storage and cleanly handles code, token, and PKCE exchanges.

  • OAuth.tools: An interactive playground built by Curity that maintains persistent workspaces and client definitions without losing state during redirects.

Option 3: Self-Host the Auth0 Playground

If you require the specific step-by-step UI of openidconnect.net for demos/training:

  1. Clone the repository from auth0/openidconnect-playground.

  2. Configure your environment variables in .env (CLIENT_ID, CLIENT_SECRET, REDIRECT_URI).

  3. Run the application locally (npm run build && npm start) on localhost, avoiding cross-domain cookie and multi-tenant session drops.

Kind Regards,
Nik

4

Thanks very much, Nik! This is very helpful!