Authentication in your project: users, settings and the Playground

Every project comes with built-in authentication. Your app can sign people up, sign them in, keep them signed in, and let them reset a forgotten password, without you running a separate user system. The users live with your project, and the same sign-in can be used to protect rows in your database (see Protect rows with row-level security).

Open the Authentication page

1. Open your project in the Console.
2. In the left sidebar, under Core Services & Infrastructure, choose Authentication.

The page shows your Total Users, a Monthly Active Users (MAUs) counter and the session lifetimes in force. Below that is the Project Users table with the columns User ID, Email, Status (Verified or Pending), Created, Last Activity and Actions.

What you can do with a user

Each row has three buttons:

• Manage opens a panel for that user. From there you can Send password reset email, Send one-time code, Send magic link, Mark email verified (or unverified), Sign out everywhere, and Set password. If the user has two-factor turned on you also see Remove two-factor. The panel also lists the user's active sessions and recent sign-in events.
• Test Sign-In signs in as that user so you can check what they see.
• Delete removes the account.

To add someone yourself, choose + Create User, enter an Email Address and a Password, and save. Accounts you create this way are marked active and verified.

Try every flow: the Auth Playground

Choose Auth Playground to run the real sign-in flows against your project: Sign in, Sign up, One-time code, Magic link, Password reset, Two-factor and Refresh token. It is not a simulation. It creates real sessions and real accounts, and it counts toward your monthly active users. Use disposable test accounts, and choose Revoke This Session when you are done.

For the one-time code, magic link and reset flows you can choose Email it to the user or Show it here (no email sent), which is handy before you have set up email.

Change how authentication behaves

Choose Settings at the top of the page. The settings window has eight tabs:

Tab	What it controls
General	Site URL, allowed redirect URLs, whether new sign-ups are allowed, self-deletion and email verification
Sign-in methods	Email and password, one-time code, magic link
Sign-up fields	Extra information to ask for at sign-up
Passwords	Minimum length and character rules
Sessions	How long sign-ins last
Emails	The wording and look of the emails your users receive
Sender domain	Send those emails from your own domain
Social login	Sign in with Google or GitHub

These are covered in Choose sign-in methods and password rules, Customize the emails your users receive and Add social login.

Use it from your app

The Authentication page includes a short code sample for the TypeScript SDK. The same calls exist in the Python, Go and Rust SDKs. See Use the TypeScript SDK for the full list.

Tip: Sign-ups and sign-ins use your project's publishable key, which is safe to put in a browser or mobile app. Anything that manages users on behalf of your app, such as listing or deleting accounts, needs the secret key and belongs on your server. See API keys.

Good to know

• Sign-in attempts are rate limited per project and per address. Past a limit the API answers with a "Too many requests" message and a wait time.
• Passwords are stored as one-way hashes. Nobody, including you, can read a user's password.
• Removing a user in the Console is permanent.