Supabase - Auth

Use Supabase to authenticate and authorize your users.

On this page

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 Postgres - 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.

Make sure any views you create for Auth data are protected.

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 Postgres - Row Level Security policies.

👉 Users

Identity

An identity is an authentication method associated with a user. Supabase Auth supports the following types of identity:

  • Email
  • Phone
  • OAuth
  • SAML

A user can have more than one identity. Anonymous users have no identity until they link an identity to their user.

👉 Identities

User Management

👉 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.users table to ensure data integrity.
  • Specify on delete cascade in the reference.

For example, a public.profiles table might look like this:

create table public.profiles (
  id uuid not null references auth.users on delete cascade,
  first_name text,
  last_name text,


  primary key (id)
);


alter table public.profiles enable row level security;
Caution

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.

To update your public.profiles table every time a user signs up, set up a trigger.

If the trigger fails, it could block signups, so test your code thoroughly.

-- inserts a row into public.profiles
create function public.handle_new_user()
returns trigger
language plpgsql
security definer set search_path = ''
as $$
begin
  insert into public.profiles (id, first_name, last_name)
  values (new.id, new.raw_user_meta_data ->> 'first_name', new.raw_user_meta_data ->> 'last_name');
  return new;
end;
$$;


-- trigger the function every time a user is created
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

Adding and retrieving user metadata#

Deleting users

Exporting users

Session

👉 Sessions

Password-based Auth

Users can associate a password with their identity using their email address or a phone number.

Note

Phone authentication is usually discouraged because phone networks recycle mobile phone numbers. Anyone receiving a recycled phone number gets access to the original user’s account.

👉 Password-based Auth

Passwordless email logins

Passwordless logins allow users to sign in without a password, by clicking a confirmation link or entering a verification code.

Passwordless login can:

  • Improve the user experience by not requiring users to create and remember a password
  • Increase security by reducing the risk of password-related security breaches
  • Reduce support burden of dealing with password resets and other password-related flows

👉 Passwordless email logins

Anonymous Sign-Ins

Enable Anonymous Sign-Ins to build apps which provide users an authenticated experience without requiring users to enter an email address, password, use an OAuth provider or provide any other PII (Personally Identifiable Information). Later, when ready, the user can link an authentication method to their account.

👉 Anonymous Sign-Ins

Social Login

Social Login (OAuth) is an open standard for authentication that allows users to log in to one website or application using their credentials from another website or application. OAuth allows users to grant third-party applications access to their online accounts without sharing their passwords.

OAuth is commonly used for things like logging in to a social media account from a third-party app. It is a secure and convenient way to authenticate users and share information between applications.

Google

Supabase Auth supports Sign in with Google for the web, native applications (Android, macOS and iOS), and Chrome extensions.

You can use Sign in with Google in two ways:

  • By writing application code for the web, native applications or Chrome extensions
  • By using Google’s pre-built solutions such as personalized sign-in buttons, One Tap or automatic sign-in

👉 Login with Google