Escribe para buscar…

Auth

Use Supabase to authenticate and authorize your users.

Esta página todavía no se ha traducido — se muestra en su idioma original:English

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.

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.

sql
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:

  • 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:

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

Estás leyendo una vista previa.

Inicia sesión con Google para leer la página completa. Una cuenta de Google incluye 5 páginas gratuitas en total; el alumnado y el profesorado leen las páginas de su curso sin límite.

Iniciar sesión