# Lessly Users

Lessly Users signs the people who use your product in, and holds a record of each of them. Your customers get a way to create an account and prove who they are; you get a directory you can search, edit, export and erase.

Everything here is scoped to one product. Its end-users are yours: they are never shared with another product on the platform, an id issued in one product means nothing in another, and the same email address may belong to a different person in each.

## The model

Four objects carry everything. They are worth reading in order, because each one belongs to the one above it.

- **Product** — your product, the tenant. It owns the configuration: which sign-in methods are on, how long a session lives, which origins may talk to Lessly Users. [Configure authentication](/ship/users/configuration) covers every setting it holds.
- **End-user** — a person who uses your product. The record is durable and its id is a stable opaque string. Store that id in your own database, not the email address: addresses change and can be reassigned. [Manage your end-users](/ship/users/user-management) is the record, field by field.
- **Identifier** — an email address that reaches an end-user. A user may hold several; exactly one is primary, and each carries its own verification state. "This user is verified" is always a statement about an address, not about the person.
- **Session** — one signed-in device. A session is the unit you revoke: ending it kills that device and nothing else. [Sessions and tokens](/ship/users/sessions-and-tokens) explains what a session issues and how your backend checks it.

Separately from their identifiers, a user holds the ways they can prove who they are: a password, a linked Google or GitHub account, an enrolled authenticator app. A user always keeps at least one usable way in — the last one cannot be removed.

## What you get

| Piece | What it is for |
|---|---|
| The API | Public endpoints your frontend calls to run sign-up and sign-in, and endpoints your backend calls to exchange, refresh and verify tokens and to administer users. |
| Prebuilt components | `<SignIn/>`, `<SignUp/>`, `<UserButton/>` and `<UserProfile/>` from `@lessly/users-react`. They render inside your own React application, on your own domain, and take their appearance from your own code through an `appearance` prop — nothing about how they look is stored on our side. |
| Client libraries | `@lessly/users` on your backend, `@lessly/users-client` in the browser, `@lessly/users-react` for React. Every documented flow has a library call. |
| The management App | Where you and your team work with the directory day to day, and where the product's authentication configuration is edited. |

## What it does not do

The first release covers the end-users of one product, and stops there:

- No organizations, teams or memberships between your end-users.
- No enterprise single sign-on.
- No SMS or phone-number authentication.
- No anonymous users.
- No passkeys, and no native mobile libraries — the browser and backend packages cover mobile applications through the same token exchange.

> **NOTE**
> Lessly Users is about the people who use *your* product. The people who *build* it — your teammates, their roles and what they can reach inside Lessly — are a different model: see [Organizations and members](/access/organizations-and-members).

## Next steps

- [Sign in your first end-user](/ship/users/quickstart): seven steps from an empty product to a signed-in user your own backend can read.
- [Configure authentication](/ship/users/configuration): turn on the methods you want, and set the policy and lifetimes they obey.
- [Run a sign-in flow](/ship/users/auth-flows): what each method asks of your code, step by step.