Lessly Users
Sign your customers in, and keep a record of every one of them.
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 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 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 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/>, <UserProfile/>, <MfaSettings/> and <PasskeySettings/> from @lessly/users-react. They render sign-in, sign-up, the account panel, two-step verification, passkeys and the way out inside your own React tree, styled by a theme you pass them. They run in your application rather than on a page of ours, so the browser never leaves your domain — your backend still mints the PKCE pair for the sign-in handoff and exchanges the code. |
| 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: read the product’s sign-in numbers, find a user, read their sessions and security history, ban or unban, invite, create, export, run an import, issue and rotate keys, register webhook endpoints, and edit the product’s authentication configuration. |
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 native mobile libraries — the browser and backend packages cover mobile applications through the same token exchange.
Next steps
- Sign in your first end-user: seven steps from an empty product to a signed-in user your own backend can read.
- Configure authentication: turn on the methods you want, and set the policy and lifetimes they obey.
- Run a sign-in flow: what each method asks of your code, step by step.
- Add two-factor authentication and Add passkeys: the two self-service screens
@lessly/users-reactships ready-made.