Firebase Auth

Use Firebase Auth with your Supabase project

Firebase Auth can be used as a third-party authentication provider alongside Supabase Auth, or standalone, with your Supabase project.

Getting started#

1. First you need to add an integration to connect your Supabase project with your Firebase project. You will need to get the Project ID in the Firebase Console.
2. Add a new Third-party Auth integration in your project's Authentication settings.
3. If you are using Third Party Auth when self hosting, create and attach restrictive RLS policies to all tables in your public schema, Storage and Realtime to prevent unauthorized access from unrelated Firebase projects.
4. Assign the role: 'authenticated' custom user claim to all your users.
5. Finally set up the Supabase client in your application.

Setup the Supabase client library#

1
2
3
4
5
6
7
import { createClient } from '@supabase/supabase-js'const supabase = createClient('https://<supabase-project>.supabase.co', 'SUPABASE_ANON_KEY', {  accessToken: async () => {    return await firebase.auth().currentUser?.getIdToken(/* forceRefresh */ false)) ?? null  },})

Add a new Third-Party Auth integration to your project#

In the dashboard navigate to your project's Authentication settings and find the Third-Party Auth section to add a new integration.

In the CLI add the following config to your supabase/config.toml file:

1
2
3
[auth.third_party.firebase]enabled = trueproject_id = "<id>"

Adding an extra layer of security to your project's RLS policies (self-hosting only)#

Firebase Auth uses a single set of JWT signing keys for all projects. This means that JWTs issued from an unrelated Firebase project to yours could access data in your Supabase project.

When using the Supabase hosted platform, JWTs coming from Firebase project IDs you have not registered will be rejected before they reach your database. When self-hosting implementing this mechanism is your responsibility. An easy way to guard against this is to create and maintain the following RLS policies for all of your tables in the public schema. You should also attach this policy to Storage buckets or Realtime channels.

It's recommended you use a restrictive Postgres Row-Level Security policy.

Restrictive RLS policies differ from regular (or permissive) policies in that they use the as restrictive clause when being defined. They do not grant permissions, but rather restrict any existing or future permissions. They're great for cases like this where the technical limitations of Firebase Auth remain separate from your app's logic.

This is an example of such an RLS policy that will restrict access to only your project's (denoted with <firebase-project-id>) users, and not any other Firebase project.

1
2
3
4
5
6
7
8
9
10
11
12
13
create policy "Restrict access to Supabase Auth and Firebase Auth for project ID <firebase-project-id>"  on table_name  as restrictive  to authenticated  using (    (auth.jwt()->>'iss' = 'https://<project-ref>.supabase.co/auth/v1')    or    (        auth.jwt()->>'iss' = 'https://securetoken.google.com/<firebase-project-id>'        and        auth.jwt()->>'aud' = '<firebase-project-id>'     )  );

If you have a lot of tables in your app, or need to manage complex RLS policies for Storage or Realtime it can be useful to define a stable Postgres function that performs the check to cut down on duplicate code. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
create function public.is_supabase_or_firebase_project_jwt()  returns bool  language sql  stable  returns null on null input  return (    (auth.jwt()->>'iss' = 'https://<project-ref>.supabase.co/auth/v1')    or    (        auth.jwt()->>'iss' = concat('https://securetoken.google.com/<firebase-project-id>')        and        auth.jwt()->>'aud' = '<firebase-project-id>'     )  );

Make sure you substitute <project-ref> with your Supabase project's ID and the <firebase-project-id> to your Firebase Project ID. Then the restrictive policies on all your tables, buckets and channels can be simplified to be:

1
2
3
4
5
create policy "Restrict access to correct Supabase and Firebase projects"  on table_name  as restrictive  to authenticated  using ((select public.is_supabase_or_firebase_project_jwt()) is true);

Assign the "role" custom claim#

Your Supabase project inspects the role claim present in all JWTs sent to it, to assign the correct Postgres role when using the Data API, Storage or Realtime authorization.

By default, Firebase JWTs do not contain a role claim in them. If you were to send such a JWT to your Supabase project, the anon role would be assigned when executing the Postgres query. Most of your app's logic will be accessible by the authenticated role.

Use Firebase Authentication functions to assign the authenticated role#

You have two choices to set up a Firebase Authentication function depending on your Firebase project's configuration:

1. Easiest: Use a blocking Firebase Authentication function but this is only available if your project uses Firebase Authentication with Identity Platform.
2. Manually assign the custom claims to all users with the admin SDK and define an onCreate Firebase Authentication Cloud Function to persist the role to all newly created users.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import { beforeUserCreated, beforeUserSignedIn } from 'firebase-functions/v2/identity'export const beforecreated = beforeUserCreated((event) => {  return {    customClaims: {      // The Supabase project will use this role to assign the `authenticated`      // Postgres role.      role: 'authenticated',    },  }})export const beforesignedin = beforeUserSignedIn((event) => {  return {    customClaims: {      // The Supabase project will use this role to assign the `authenticated`      // Postgres role.      role: 'authenticated',    },  }})

Finally deploy your functions for the changes to take effect:

1
firebase deploy --only functions

Note that these functions are only called on new sign-ups and sign-ins. Existing users will not have these claims in their ID tokens. You will need to use the admin SDK to assign the role custom claim to all users. Make sure you do this after the blocking Firebase Authentication functions as described above are deployed.

Use the admin SDK to assign the role custom claim to all users#

You need to run a script that will assign the role: 'authenticated' custom claim to all of your existing Firebase Authentication users. You can do this by combining the list users and set custom user claims admin APIs. An example script is provided below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
'use strict';const { initializeApp } = require('firebase-admin/app');const { getAuth } = require('firebase-admin/auth');initializeApp();async function setRoleCustomClaim() => {  let nextPageToken = undefined  do {    const listUsersResult = await getAuth().listUsers(1000, nextPageToken)    nextPageToken = listUsersResult.pageToken    await Promise.all(listUsersResult.users.map(async (userRecord) => {      try {        await getAuth().setCustomUserClaims(userRecord.id, {          role: 'authenticated'        })      } catch (error) {        console.error('Failed to set custom role for user', userRecord.id)      }    })  } while (nextPageToken);};setRoleCustomClaim().then(() => process.exit(0))

After all users have received the role: 'authenticated' claim, it will appear in all newly issued ID tokens for the user.