Skip to main content

​
Users

A user in Dynamic is created when someone successfully authenticates by 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 section of the Dynamic Developer Console, 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

​
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) that serves as the session credential. Key aspects of sessions:
  • Creation: A session begins when Dynamic issues a JWT after successful authentication.
  • Duration: A session lasts until its refresh window ends (30 days from first sign-in) or it is revoked. Individual JWTs expire sooner, and the SDK rotates them within that window. Configure the per-token lifetime in your dashboard security settings; the maximum is 30 days.
  • 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 refresh window closes, 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. For JWT structure and verification, see 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.

​
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: 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.
Last modified on September 21, 2026