Documentation Index

Fetch the complete documentation index at: https://docs.odeus.ai/llms.txt Use this file to discover all available pages before exploring further.

Session Management

Odeus protects user sessions with short-lived access tokens, rotating refresh tokens, and a cap on the number of concurrent sessions per user.

Overview

When a user signs in to Odeus, the platform issues a pair of tokens:

• An access token (JWT) that authorizes API requests. It is short-lived and expires automatically.
• A refresh token that is used to obtain a new access token when the current one expires, so the user stays signed in without re-entering credentials.

This model keeps long-lived credentials off the wire for most requests while still giving people a smooth, uninterrupted experience.

How sessions work

Short-lived access tokens

Every API call is authorized with a JSON Web Token (JWT) that has a limited time-to-live (TTL). Once the access token expires, it can no longer be used; the client must present a valid refresh token to get a new one. Because access tokens are short-lived, a leaked token has only a small window in which it is useful.

Refresh-token rotation

Odeus rotates refresh tokens. Each time a refresh token is exchanged for a new access token, the old refresh token is invalidated and a new one is issued. This means a refresh token can be used only once. If an old refresh token is ever replayed, it will be rejected, which limits the value of a stolen token.

Concurrent-session cap

Each user can hold a limited number of active sessions at the same time (currently up to 10 concurrent sessions per user). When a user signs in on a new device or browser beyond this limit, the oldest session is retired. This bounds how many places a single account can be signed in from at once.

What this means for your users

• Users normally stay signed in across the working day without re-entering credentials, because refresh happens transparently in the background.
• Signing out invalidates the session's tokens so they can no longer be used.
• Signing in from many devices is supported up to the per-user session limit; beyond that, the least-recently-used session is dropped.

Authentication methods

Sessions are established after a successful sign-in. Odeus supports:

• Email magic-link / one-time code sign-in.
• Google OAuth single sign-on.

Once authenticated, the session lifecycle (access TTL, refresh rotation, and the concurrent-session cap) applies regardless of which method was used to sign in.

SAML/SSO with identity providers such as Entra ID and Okta, SCIM provisioning, and IP-based access restrictions are on the Odeus governance roadmap and are not generally available yet. This page describes the session controls that ship today.

Need help?

If you have questions about session security or authentication, reach out to [email protected].