User Management
Manage your users with Supabase Auth
The user object
The user object stores all the information related to a user in your application. The user object can be retrieved using one of these methods:
supabase.auth.getUser()
- Retrieve a user object as an admin using
supabase.auth.admin.getUserById()
A user can sign in with one of the following methods:
- Password-based method (with email or phone)
- Passwordless method (with email or phone)
- OAuth
- SAML SSO
An identity describes the authentication method that a user can use to sign in. A user can have multiple identities. These are the types of identities supported:
- Phone
- OAuth
- SAML
A user with an email or phone identity will be able to sign in with either a password or passwordless method (e.g. use a one-time password (OTP) or magiclink). By default, a user with an unverified email or phone number will not be able to sign in.
The user object contains the following attributes:
Attributes | Type | Description |
---|---|---|
id | string | The unique id of the identity of the user. |
aud | string | The audience claim. |
role | string | The role claim used by Postgres to perform Role Level Security (RLS) checks. |
string | The user's email address. | |
email_confirmed_at | string | The timestamp that the user's email was confirmed. If null, it means that the user's email is not confirmed. |
phone | string | The user's phone number. |
phone_confirmed_at | string | The timestamp that the user's phone was confirmed. If null, it means that the user's phone is not confirmed. |
confirmed_at | string | The timestamp that either the user's email or phone was confirmed. If null, it means that the user does not have a confirmed email address and phone number. |
last_sign_in_at | string | The timestamp that the user last signed in. |
app_metadata | object | The provider attribute indicates the first provider that the user used to sign up with. The providers attribute indicates the list of providers that the user can use to login with. |
user_metadata | object | Defaults to the first provider's identity data but can contain additional custom user metadata if specified. Refer to User Identity for more information about the identity object. |
identities | UserIdentity[] | Contains an object array of identities linked to the user. |
created_at | string | The timestamp that the user was created. |
updated_at | string | The timestamp that the user was last updated. |
Configuration
Supabase Auth provides these configuration options to control user access to your application:
-
Allow new users to sign up: Users will be able to sign up. If this config is disabled, only existing users can sign in.
-
Allow unverified email sign in: Users will not need to have a verified email address to sign in.
- If enabled, you can structure your RLS policies to provide different access controls to a user with an unverified email and a user with a verified email. For example,
_13-- Allows a user to read all posts regardless of whether they have a verified email address_13create policy "policy_name"_13ON public.posts_13for select to authenticated using (_13true_13);_13_13-- Only allow users with a verified email address to insert posts_13create policy "policy_name"_13ON public.posts_13for insert to authenticated with check (_13(select auth.jwt()->>'email_verified') is true_13); -
Confirm Email (Deprecated): Users will need to confirm their email address before signing in for the first time.
- Having Confirm Email disabled assumes that the user's email does not need to be verified in order to login and implicitly confirms the user's email in the database.
- If you previously relied on this config to autoconfirm a user's email address, you can switch to use Allow unverified email sign in instead. This new option allows the user to sign in with an unverified email which you can keep track of through the user object. It provides more versatility if you require your users to verify their email address in the future since you can structure your RLS policies to check the user's
email_verified
field.