Auth
Use Supabase to authenticate and authorize your users.
Introduction
Supabase Auth makes it easy to implement authentication and authorization in your app.
Your users can use many popular Auth methods, including password, magic link, one-time password (OTP), social login, and single sign-on (SSO).
About authentication and authorization
Authentication and authorization are the core responsibilities of any Auth system.
- Authentication means checking that a user is who they say they are.
- Authorization means checking what resources a user is allowed to access.
Supabase Auth uses JWT for authentication. For a complete reference of all JWT fields, see the JWT Fields Reference. Auth integrates with Supabase’s database features, making it easy to use Row Level Security for authorization.
Auth service
The Auth service is an Auth API server written and maintained by Supabase. It is a fork of the GoTrue project, originally created by Netlify.
When you deploy a new Supabase project, we deploy an instance of this server alongside your database, and inject your database with the required Auth schema.
The Auth service is responsible for:
- Validating, issuing, and refreshing JWTs
- Serving as the intermediary between your app and Auth information in the database
- Communicating with external providers for Social Login and SSO
Postgres
Supabase Auth uses the auth schema in your Postgres database to store user tables and other information. For security, this schema is not exposed on the auto-generated API.
You can connect Auth information to your own objects using database Trigger and Foreign Key.
Auth also enables access control to your database’s automatically generated REST API. When using Supabase SDKs, your data requests are automatically sent with the user’s Auth Token. The Auth Token scopes database access on a row-by-row level when used along with Row Level Security policies.
Make sure that any views you create for Auth data are adequately protected by enabling RLS or revoking grants.
Starting in Postgres version 15, views inherit the RLS policies of the underlying tables if created with security_invoker. Views in earlier versions, or those created without security_invoker, inherit the permissions of the owner, who can bypass RLS policies.
Getting started
Launch a new project in the Supabase Dashboard.
Your new database has a table for storing your users. You can see that this table is currently empty by running some SQL in the SQL Editor.
select * from auth.users;Create a new project with Deno:
👉 Use Supabase Auth with React Native
User
A user in Supabase Auth is someone with a user ID, stored in the Auth schema. Once someone is a user, they can be issued an Access Token, which can be used to access Supabase endpoints. The token is tied to the user, so you can restrict access to resources via Row Level Security policies using the auth.uid() function.
👉 Users
Identity
An identity is an authentication method associated with a user. Supabase Auth supports the following types of identity:
- Phone
- OAuth
- SAML
A user can have more than one identity. Anonymous users have no identity until they link an identity to their user.
User Management
You can view your users on the Users page of the Dashboard.
You can also view the contents of the Auth schema in the Table Editor.
Accessing user data via API
For security, the Auth schema is not exposed in the auto-generated API. If you want to access users data via the API, you can create your own user tables in the public schema.
- Make sure to protect the table by enabling Row Level Security.
- Reference the
auth.userstable to ensure data integrity. - Specify
on delete cascadein the reference.
For example, a public.profiles table might look like this:
(
id uuid not null references auth.users on delete cascade,
first_name text,
last_name text,
primary key (id)
);
public.profiles enable row level security;Only use primary keys as foreign key references for schemas and tables like auth.users which are managed by Supabase. Postgres lets you specify a foreign key reference for columns backed by a unique index (not necessarily primary keys).
Primary keys are guaranteed not to change. Columns, indices, constraints or other database objects managed by Supabase may change at any time and you should be careful when referencing them directly.
You're reading a preview.
Sign in with Google to read the full page. A Google account includes 5 free pages in total; students and teachers read their course pages without limit.
Sign in