Overview

The login → refresh → logout lifecycle, plus the admin operations on top of it.

A session in Febasi Auth is the lifetime of a refresh token. Every successful login opens one; every logout closes one; rotations replace one without a gap. This topic walks the full lifecycle and covers the admin operations that let you inspect and end sessions on someone else's behalf.

The lifecycle in one picture

POST /login        ──▶  access token (15m) + refresh token (7d)  ──▶  app stores both
                                                                      │
                                                                      │ access token expires
                                                                      ▼
POST /refresh      ──▶  new access token + new refresh token       ──▶  old refresh token revoked
                                                                      │
                                                                      │ user signs out
                                                                      ▼
POST /logout       ──▶  refresh token revoked                       ──▶  no future refresh

Defaults are tenant-configurable. Token lifetimes, max concurrent sessions, and the eviction behavior all live under authConfig and rotate per tenant.

What's in this topic

Login

The POST /login call, the identifier types, password policy, brute-force protections, and the dummy-bcrypt timing-attack mitigation.

Refresh tokens

Token rotation, the atomic transaction model, and how session limits interact with login.

Session management

The admin operations: list active sessions, revoke a single one, revoke all sessions for a user, revoke every session in the tenant.

Summary

Cheat sheet: the four calls, the common errors, the configuration knobs.

Concepts → Sessions — the data model behind a session row.
Concepts → Authentication — what /login actually does at the password and token level.
Concepts → JWT secrets per tenant — which key signs the access token.