> ## Documentation Index
> Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Concepts

> Core concepts in Dynamic authentication — Users, Sessions, Wallets, and Visitors.

## Users

A **user** in Dynamic is created when someone successfully authenticates — proving ownership of a credential (wallet signature, email OTP, social login, etc.). Once authenticated a user can be issued access tokens. Each user has:

* A unique **user ID** (`sub` claim in the JWT)
* One or more **verified credentials** (wallets, email addresses, social accounts, passkeys, or external auth identifiers)
* Optional profile information collected during onboarding (email, alias, name, etc.)

Users are managed in the [Users & Visitors](https://app.dynamic.xyz/dashboard/users) section of the Dynamic Dashboard, where you can view their wallets, sessions, and collected information.

A user can be **authenticated** (JWT issued, session active) but not yet **fully logged in** if they still need to complete required information capture or if an embedded wallet is still being created. Your SDK provides ways to distinguish between these states. See your SDK's docs for details on handling these intermediate states.

### The user object

See the user object reference [here](/api-reference/schemas/User)

## Sessions

A **session** represents an active authenticated period for a user. When a user authenticates, Dynamic creates a session and issues a [JWT (JSON Web Token)](/overview/authentication/tokens) that serves as the session credential.

Key aspects of sessions:

* **Creation**: A session begins when Dynamic issues a JWT after successful authentication.
* **Duration**: Sessions last until the JWT expires. The maximum JWT lifetime is 30 days, configurable in your [dashboard security settings](/overview/developer-dashboard/security).
* **Storage**: The JWT is stored either in a **cookie** (browser sends it automatically on same-origin requests) or in **in-app storage** (your app reads it and sends it explicitly), depending on your project configuration.
* **Expiry**: When the JWT expires, the SDK ends the session automatically — the user object and token are cleared, and the user must re-authenticate.
* **Updates**: When a user links a new credential (e.g. connects another wallet), Dynamic refreshes the JWT with updated claims without ending the session.
* **Concurrent**: Users can have multiple sessions active at the same time.

For ending sessions programmatically, see [Revoking Sessions](/overview/authentication/revoking-sessions). For JWT structure and verification, see [Tokens](/overview/authentication/tokens).

## Wallets

In the context of authentication, Dynamic interacts with wallets in several ways:

* **External wallets** (MetaMask, Phantom, Coinbase Wallet, etc.) can be used as an authentication method — the user connects the wallet and signs a message to prove ownership.
* **Embedded wallets** are created by Dynamic after authentication. They are not part of the authentication step itself — the JWT is issued first, and wallet creation happens afterward (either automatically on signup or on-demand).
* **Wallet credentials** appear in the JWT's `verified_credentials` claim after authentication, allowing your backend to know which wallets belong to the user.

For a full overview of wallet types (embedded, external, server, global) and when to use each, see [Wallets Overview](/overview/wallets/overview).

## Visitors

A **visitor** is someone who connects an external wallet but does **not** sign a message to prove ownership. Visitors exist only in the context of external wallets configured in **connect-only** mode.

Key differences from authenticated users:

|                              | Visitor | Authenticated user |
| ---------------------------- | ------- | ------------------ |
| Wallet connected             | Yes     | Yes                |
| Message signed               | No      | Yes                |
| JWT issued                   | No      | Yes                |
| User record created          | No      | Yes                |
| Access control applies       | No      | Yes                |
| Information capture applies  | No      | Yes                |
| Can use backend verification | No      | Yes                |

Visitors can still interact with your app using their connected wallet (e.g. read on-chain data), but they cannot access features that require a JWT or a user record.

You can configure connect-only mode in your project settings and later prompt visitors to authenticate (sign) when they need features that require a JWT. See your SDK's docs on connect-only vs connect-and-sign for implementation details.