The Settings card under Application → Authentication is the OAuth 2.0 / Authaz Sign-In configuration surface. It's where you tell Authaz: which URLs your app will be redirected to, what scopes it can request, how long tokens live, and how sessions behave. Most production issues — redirect_uri_mismatch, expired-token loops, "user keeps getting logged out" — trace back to this page.
Exact match.https://yourapp.com/callback does not match https://yourapp.com/callback/. Trailing slashes matter.
Scheme matters.https and http are different. Production should be https only; localhost is the standard exception.
No wildcards in production.https://*.yourapp.com/callback is not valid. Add each subdomain explicitly. (Localhost can use any port — http://localhost:* is treated as a special case.)
Query strings are stripped before matching.?utm=... on the way out is fine.
A mismatch returns error=invalid_request, error_description=redirect_uri_mismatch and the user never reaches your callback. The audit log records every mismatch so you can see exactly what was attempted.
postLogoutRedirectUris is the same allow-list but for the logout flow — where users land after POST /oauth2/logout. Same matching rules.
allowedScopes is the menu of OAuth scopes your application is allowed to request. Authaz rejects any token request whose scope parameter contains a value not on this list.
Default: ["openid", "profile", "email"]. Standard OIDC scopes plus any custom scopes you've defined for resources.
Scope
What it grants in the access token
openid
Required for OIDC. Includes a stable sub claim.
profile
name, given_name, family_name, picture.
email
email, email_verified.
offline_access
A refresh token alongside the access token.
Custom (e.g. invoices:read)
Permission scopes you've defined in your resource catalog.
Add only what your app actually uses. Over-broad scopes leak data into tokens and bloat their size.
Authaz rotates refresh tokens by default — every successful refresh issues a new refresh token and invalidates the previous one. If your client retries an old refresh token, Authaz returns 400 invalid_grant and revokes the entire refresh-token family. This catches token theft.
Always store the refresh token returned in each response, not the original.
Authaz will use that tenant for the entire authentication flow (Authaz Sign-In UX, provider routing, role resolution, the tenant_id claim on the issued tokens). Requests without tenant_id are rejected with 400 missing_tenant_hint.
Use this when:
Your app's URL structure already encodes the tenant (e.g. acme.yourapp.com calls /oauth2/authorize?tenant_id=tenant_acme).
You don't want users to see a tenant picker on Authaz Sign-In.
You're running isolated auth and the tenant must be known up front to pick the right providers.
Leave it false (the default) when:
A user might belong to multiple tenants and should choose at login time.
Your application is single-tenant (the parameter would be ignored anyway).
sessionTimeoutMinutes is the absolute lifetime of a Authaz Sign-In session — after this many minutes, the user must sign in again, no matter how active they are.
rememberMeTimeoutMinutes is the extended lifetime when the user clicks Remember me. The default of 43200 (30 days) is reasonable for most apps; banking and healthcare apps usually want this much shorter (~480 min, matching the regular session) or disabled entirely.
Both work in concert with the access-token lifetime: the access token is the per-request credential, the session is the cookie that lets Authaz Sign-In skip re-authentication on the next token request.
applicationCredentialId links this configuration to an OAuth client credential — the client_id and client_secret your app sends on POST /oauth2/token. The dashboard creates one for you on first save; you can also pre-create one under the API Keys page and link it here.
The credential carries:
client_id — public, included in every authorize URL.
client_secret — confidential, only sent server-side from your backend.
Rotate the secret when:
It's been leaked.
A team member with access leaves.
Annually as part of routine hygiene.
Rotation issues a new secret with a 24-hour grace period — both the old and new secrets work during that window so you can deploy without downtime.
