Session policy

auth-policy.json at the project root controls the refresh token architecture, including how many devices a user may be signed in on at once.

Limits are set per surface, because the right number differs between them:

Eviction

When a user exceeds the configured limit, the oldest active session is evicted rather than the new login being refused:

Refresh request from device #3
  → check max sessions (limit: 2)
  → limit exceeded
  → evict oldest active session (device #1)
  → issue new access + refresh tokens

The trade-off is deliberate. Refusing the new login is more secure in the strictest reading, but it strands a user who has lost a device with no way back in. Evicting the oldest keeps the limit meaningful while leaving the person in front of you able to work.

SSO sessions

A session created through SSO is an ordinary session. The provider is used to assert an identity once, at login; the moment it confirms who the user is, the engine issues its own tokens and the provider is never contacted again — its access token is discarded rather than stored.

So an SSO session is indistinguishable from a password one: the same access token, the same rotating refresh token, the same session limits and eviction described above, and the same JwtStrategy guarding every later API call.

For obtaining each provider's credentials, see SSO providers.