Go to developer

Sessions

KEYRA completes verification and issues a one-time validation token. Your app creates and manages the long-lived application session.

On this page

Who owns the session

ArtifactOwnerLifetime role
Authorization codeKEYRA → browserShort-lived; exchanged once
access_token / verification_tokenBrowser → your backendValidate once; then discard for auth decisions
Application sessionYour backendYour product's login state
PKCE keys (keyra:oauth:flow:v2, keyra_sdk_transient)Browser helpersFlow-only; not app auth

Handoff sequence

  1. Browser completes popup/redirect and holds access_token.
  2. Browser POSTs the token to your API (credentials: include).
  3. Server calls validateVerification / POST /verify/validate.
  4. On valid: true, map KEYRA user → your account and set your session.
  5. Subsequent requests authorize via your session — not by replaying the KEYRA token.

Browser responsibilities

  • Do not treat onSuccess / verify() alone as logged-in.
  • Do not store KEYRA tokens or user objects in localStorage as the application session.
  • Prefer redirecting to an authenticated app route only after your API confirms session creation.

Server responsibilities

  • Expect 409 verification_token_already_used on replay — design idempotent login UX.
  • Bind the session to your user id, not solely to a raw KEYRA token string.
  • Log support ids (e.g. verification id) — not full tokens.

Logout

Clear your application session. Clearing PKCE sessionStorage keys is optional hygiene after a completed flow; it does not revoke KEYRA tokens already validated. Re-authentication requires a new OAuth Verify run and a new validate.