Sessions & tokens

Sessions

After login, Authara maintains a server-side session (cookie-based) at the issuer.

• Lifetime: 14 days by default, overridable via environment.
• Single sign-on: because the session lives at the Authara issuer, a user already signed in is silently re-authorized for another of your apps (subject to consent/redirect rules) — the basis for SSO across all your products.
• Silent auth: prompt=none lets an app refresh tokens without UI when a session exists.
• Sign-out: the SDK's signOut() hits the end_session_endpoint, clears the session, and redirects to a post-logout URI. Federated / back-channel logout is supported.

Tokens

Token	Use	Notes
ID token (JWT)	who the user is	Standard OIDC claims; verify with jwks_uri.
Access token	call a protected API	Audience = the API resource indicator; carries granted scopes.
Refresh token	new access tokens without re-login	Rotated on use; reuse is detected and revokes the chain. Absolute cap ~1 year.

Verifying tokens on your API

Always validate — never trust a bearer token blindly:

1. Verify the JWT signature against {ENDPOINT}/oidc/jwks.
2. Check iss = your issuer, aud = your API's resource indicator, exp not passed.
3. Enforce the required scope.

Best practices

• Request the minimum scopes an app needs, scoped to a specific API resource.
• Keep refresh tokens server-side for confidential apps; for SPAs rely on the SDK's rotation + short-lived access tokens.
• Treat the ID token as identity, the access token as authorization — don't send ID tokens to APIs.
• If your app must assert MFA happened, check the amr claim on the ID token (see MFA).