Smoke-test the IdP with oidcdebugger.com

oidcdebugger.com is a free online tool that acts as a relying party. You paste in Scrydon's authorize URL, your client ID and scopes, hit Send request, and get back an authorization code. You then exchange the code for tokens with a single curl call and decode the ID token on jwt.io.

This takes about five minutes and proves your Scrydon tenant is serving OIDC correctly end-to-end.

Prerequisites

• A Registered App (client) created under Settings → Organization → Registered Apps. See Register an OAuth client.
• The Identity tab of Settings → Platform → Identity open in another window — you'll copy URLs from there.

1. Add the debugger's callback to your client

oidcdebugger posts the authorization code back to https://oidcdebugger.com/debug. Scrydon only accepts redirects that match your client's registered redirect URIs, so you must add this URL as an allowed redirect for your test client.

2. Start the authorization flow

3. Exchange the code for tokens

oidcdebugger's result page shows a code=... parameter in the URL. Exchange it for an ID token and access token.

Copy the Code verifier from oidcdebugger (it generated this for PKCE) and run the following from your terminal — adjust {AUTH_URL}, {CLIENT_ID}, {CODE}, and {CODE_VERIFIER}:

curl -X POST "{AUTH_URL}/api/auth/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code={CODE}" \
  -d "redirect_uri=https://oidcdebugger.com/debug" \
  -d "client_id={CLIENT_ID}" \
  -d "code_verifier={CODE_VERIFIER}"

You should get back a JSON response with access_token, id_token, refresh_token (if you requested offline_access), token_type, and expires_in.

4. Decode the ID token

Paste the id_token into jwt.io. The payload will show:

{
  "iss": "https://staging.api-platform.scrydon.com",
  "sub": "usr_...",
  "aud": "your-client-id",
  "exp": 1234567890,
  "iat": 1234567890,
  "email": "you@example.com",
  "name": "Your Name",
  "org_id": "org_...",
  "workspace_id": "ws_...",
  "environment_id": "env_..."
}

The last three claims (org_id, workspace_id, environment_id) are Scrydon-specific — your Mini App uses them to route API calls to the right tenant and workspace.

To verify the signature locally, fetch the JWKS from the Identity tab URL ({AUTH_URL}/api/auth/.well-known/jwks) and paste it into jwt.io's Verify Signature panel.

5. Call the Userinfo endpoint

A final sanity check — use the access token to call Userinfo:

curl "{AUTH_URL}/api/auth/oauth2/userinfo" \
  -H "Authorization: Bearer {ACCESS_TOKEN}"

You should get back the same identity claims as a JSON object.

Troubleshooting

404 on /api/auth/.well-known/openid-configuration or /oauth2/token

First, confirm whether the problem is DNS, ingress, or the app:

# 1. Does the hostname resolve at all?
curl -I "{AUTH_URL}"

# 2. Does any Better Auth endpoint answer? /api/auth/session is always mounted.
curl -s -o /dev/null -w "%{http_code}\n" "{AUTH_URL}/api/auth/session"

# 3. Is the OIDC plugin mounted? Discovery should return 200 + JSON.
curl -s "{AUTH_URL}/api/auth/.well-known/openid-configuration" | head -c 500

Interpret the results:

• All three fail / DNS fails — the hostname shown in the UI doesn't resolve. The PUBLIC_AUTH_URL env var on the platform pod is set to a hostname that isn't in DNS or isn't routed by the ingress. Ask the cluster operator to either fix DNS / the ingress, or update PUBLIC_AUTH_URL to point to the host where the auth pod is actually published.
• /session works, /oauth2/* 404s — the auth app is reachable but the @better-auth/oauth-provider plugin isn't loaded in the running build. This is the migration from the legacy oidcProvider. Confirm the deployed image contains the plugin (look for oauthProvider( in packages/multi-tenancy/src/auth/server/auth.ts at the deployed commit).
• All three work — your client ID is probably for a different environment, or your client doesn't have the redirect URI registered. Go back to step 1 of this page.

The platform app also exposes /api/auth/* as a proxy to the auth host. Prefer hitting the auth host directly for tooling like oidcdebugger — it avoids any proxy layer and matches what library SDKs will do in production.

invalid_client during the token exchange

• The client ID you used in step 2 doesn't match the one in step 3. Mini Apps issue per-environment client IDs — make sure you used the same one consistently.

invalid_grant: code verifier does not match code challenge

• oidcdebugger generates a fresh code verifier per request. If you refreshed the page between step 2 and step 3, the verifier shown was regenerated. Repeat step 2 to get a fresh code + verifier pair.

redirect_uri mismatch

• https://oidcdebugger.com/debug was not added to the client's redirect URIs. Go back to step 1 and save again.

The sign-in screen loops back to itself

• Your Scrydon session likely expired mid-flow. Clear cookies for the tenant host and retry.