Find the next check

Follow the request from the browser to the identity service, back through your callback, and into the protected API. Fix the first boundary that fails. Keep state, PKCE, token verification, and CSRF enabled while diagnosing the problem.

Symptom	Check next
No tenant or application access	Confirm beta access and the tenant your administrator granted you
Discovery fails	Check the configured issuer and fetch its `/.well-known/oauth-authorization-server` document from the backend
Redirect URI rejected	Compare scheme, host, port, path, and query in the registration and application configuration
Local HTTP callback refused	Use a Development registration for a localhost web callback
`invalid_client`	Check the client ID, secret, confidential-client setting, and environment; creating the registration does not create its secret
Sign-up unavailable	Check the tenant's sign-up mode and enabled sign-in methods; do not bypass a closed or waitlisted policy

The issuer is not the dashboard URL. A social provider's callback returns to the identity service; your application's callback receives the result from that service. They are two different registrations.

The user signs in but the callback fails

Unknown state or missing transient cookie: check whether the callback uses the same browser and application host that started the flow. Check cookie attributes, the pending-state secret, and whether every backend instance uses the same configuration and shared storage. Expired state should start a new login rather than being accepted without verification.

invalid_grant during the code exchange: an authorization code may be expired, already consumed, or paired with the wrong callback or PKCE verifier. Start a fresh flow and inspect the request's configuration. Do not replay a captured code or weaken verification to make it pass.

Login works on one instance only: the callback may arrive at a different instance. A process-local session or pending-state store cannot reliably serve that flow. See session readiness.

The app looks signed in but the API refuses

Result	Check next
`401`	Confirm the request carries the application's session cookie and the backend can validate its access token
`403` on a BFF request	Use `BffClient` or supply the configured CSRF header from a same-origin client
Valid token but missing API scope	Compare the requested scope with the client's allowed scope and the route's requirement
Valid token but missing application permission	Check the role assignment and the organization or resource the operation actually targets
A profile field is missing	Read UserInfo with `profile` or `email` as appropriate; an access token is not a full profile
A JWT is rejected	Check the expected issuer, audience, signing key, algorithm, and expiry

Do not copy a bearer token into browser storage to work around a cookie problem. The BFF integration guide shows how the browser calls the application while tokens stay on the backend.

A role change seems to do nothing

Check where the answer came from. The browser's session projection may still contain the values captured during login. Authorize from the validated request or an appropriate live permission check, not that UI copy.

An offline JWT carries the claims from issuance until it expires. An opaque token can be introspected for current state, but your own caching can make that answer older. An active-organization claim is scoped to that organization; it does not answer a question about a different organization or a specific resource. See permissions and roles.

Refresh or logout behaves unexpectedly

For invalid_grant during refresh, check expiry, revocation, and whether two requests tried to rotate the same credential. Preserve atomic store updates and the package's rotation behavior. End the failed session and start login again instead of retrying a rejected refresh token indefinitely.

For sign-out, distinguish the application session from the identity service's session. A new login can return without another password prompt if the tenant's session is still valid. Test the exact local or SSO logout behavior your UI promises.

Bring useful information to support

Include the environment, the failing step, the HTTP status or error code, approximate time, runtime and package versions, and a minimal reproduction. Use your agreed beta support channel. Redact secrets, passwords, cookies, authorization codes, and token values. Callback URLs can contain credentials in the query string; report the registered URL rather than a captured login URL.

Next: return to your first sign-in or production readiness.