For AI agents: the complete documentation index is available at https://payhon.github.io/AppKernia/en-US/llms.txt, the full documentation bundle is available at https://payhon.github.io/AppKernia/en-US/llms-full.txt, and this page is available as Markdown at https://payhon.github.io/AppKernia/en-US/concepts/authentication.md.
AppKernia

Authentication and sessions

TokenPurposeClient storageServer storage
Access tokenShort-lived API identityMemory only in Admin and MobileNot a long-lived session record
Refresh tokenRotating session credentialAdmin Secure HttpOnly cookie; Mobile system secure storageSHA-256 hash only

Access tokens use Ed25519/EdDSA, expire after about 15 minutes by default, and isolate ak-mobile, ak-admin, and ak-api audiences.

How sign-in creates a session

The sign-in entry point first establishes the Mobile or Admin audience. Only after verifying account, app, and tenant membership does the server create a session family; plaintext passwords and refresh tokens never enter the database or logs.

Refresh rotation

Every refresh atomically consumes the old token and creates a new one. Only one concurrent use can succeed; subsequent reuse revokes the full session chain.

Only one concurrent use of an old token can succeed. Reuse of an already consumed token revokes the session family and creates a security event.

Where a session ends

Session validity is a server fact. After a stable unauthorized result, clients clear local identity and tenant-scoped cache rather than relying on a hidden page or stale permission snapshot.

  • 401 refresh is single-flight and retries the original request at most once.
  • 403 never triggers refresh.
  • Writes without idempotency are not replayed automatically.
  • Logout, tenant switch, and session invalidation clear protected caches.
  • Admin refresh tokens use only a Secure HttpOnly cookie; Mobile refresh tokens use only system secure storage.
  • Access tokens never enter localStorage, sessionStorage, IndexedDB, or ordinary uni storage.