SAML terminology: EntityID
EntityID is a globally unique ID (usually a URL) that identifies an Identity Provider or Service Provider across the world.
Supabase · Auth · all subjects
authentication/concepts
93 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
SAML terminology: NameID
NameID is a unique ID (usually an email address) that identifies a user at an Identity Provider.
SAML terminology: Metadata
Metadata is an XML document that describes the features and configuration of an Identity Provider or Service Provider. It can be a standalone document or as a URL. Usually (but not always) the EntityID is the URL at which you can access the Metadata.
Rate limit exceeded returns 429 Too Many Requests
When Supabase Auth rate limits are exceeded, a 429 Too Many Requests HTTP error is returned.
Supabase Auth rate limiting uses token bucket algorithm
Supabase Auth uses a token bucket algorithm for endpoint operations that are limited by IP address. Each bucket has a maximum capacity of 30 requests. When the bucket is full, brief bursts of up to 30 requests can be allowed in a short period. Once the bucket empties, requests are rate limited until tokens refill. The rate limit defines the rate at which the bucket is refilled. A client that has been idle will tolerate a brief spike in traffic, but sustained requests above the rate limit are denied.
Rate limits can be configured in dashboard or Management API
Supabase Auth rate limits can be configured in the project dashboard under Authentication > Rate Limits. They can also be managed using the Management API with endpoints at https://api.supabase.com/v1/projects/{PROJECT_REF}/config/auth. Configuration requires a SUPABASE_ACCESS_TOKEN from https://supabase.com/dashboard/account/tokens.
Rate limit parameters configurable via Management API
The following rate limit parameters can be configured via the Management API PATCH endpoint: rate_limit_anonymous_users, rate_limit_email_sent, rate_limit_sms_sent, rate_limit_verify, rate_limit_token_refresh, rate_limit_otp, and rate_limit_web3. Each parameter accepts an integer value representing the rate limit quota.
IP address forwarding for rate limiting
Supabase Auth uses the client's IP address for rate limiting by default. When using server-side frameworks or proxies, the end-user IP address can be forwarded to avoid being rate limited based on the server-side client's IP. To use a forwarded IP address, set the Sb-Forwarded-For header to the end-user IP address and make a request with a secret API key (keys starting with sb_secret). Publishable API keys and legacy anon/service_role API keys are not supported.
IP address forwarding must be explicitly enabled
IP address forwarding is disabled by default and must be explicitly enabled for new projects. This feature can be enabled in the project dashboard under Authentication > Rate Limits in the IP Address Forwarding section, or via the Management API by setting security_sb_forwarded_for_enabled to true.
Set Sb-Forwarded-For header in Supabase SDK
When IP address forwarding is enabled, the Sb-Forwarded-For header can be set using the Supabase SDK. In TypeScript with the SSR client, pass the header in the global headers configuration when creating the server client with a secret key.
Get current rate limits via Management API
Current rate limit configuration can be retrieved using a GET request to https://api.supabase.com/v1/projects/{PROJECT_REF}/config/auth with Authorization Bearer token. Filter results using jq to show only keys starting with 'rate_limit_'.
Protected navigation in React Native uses AuthContext and SplashScreen
To protect app navigation in Expo React Native, create an AuthContext as a React context to manage the authentication session accessible from any component. Create an AuthProvider component to manage the authentication session throughout the app. Use Expo's SplashScreen to display a loading screen while fetching the user profile and verifying authentication status. Implement protected routes by wrapping navigation with AuthProvider and SplashScreenController components.
Access token and refresh token issued by Supabase Auth
When a user authenticates with Supabase Auth, two pieces of information are issued by the server: an access token in the form of a JWT, and a refresh token which is a randomly generated string.
JWT vs traditional session benefits
JWT-based approach using access and refresh tokens provides benefits over traditional sessions: session information is encoded within the short-lived access token enabling transfer across APIs and systems without dependence on a central server's availability; enhances application tolerance to transient failures or performance issues; proactively refreshing the access token allows the application to function reliably even during significant outages; better for cost optimization and scaling as the authentication system only handles traffic for this use case.
Assign role custom claim to Firebase Auth users
All Firebase Auth users must have the role: 'authenticated' custom claim set so that Supabase assigns the authenticated Postgres role instead of the anon role when executing queries. Without this claim, the anon role is assigned by default.
customClaims vs sessionClaims in Firebase blocking functions
customClaims are saved in the Firebase user profile and persist across sign-ins. sessionClaims are not saved in the user profile but remain valid for as long as the user is signed in. Use customClaims for persistent attributes and sessionClaims for temporary session-specific data.
Firebase JWT role claim not present by default
By default, Firebase JWTs do not contain a role claim. If sent to Supabase without the claim, the anon role will be assigned instead of authenticated. The role claim must be explicitly set via blocking functions or admin SDK.
Identity types
An identity describes the authentication method that a user can use to sign in. Supported identity types are: Email, Phone, OAuth, and SAML. A user can have multiple identities.
User object attributes table
User object attributes: id (string, unique id of the identity of the user), aud (string, audience claim), role (string, role claim used by Postgres for Row Level Security checks), email (string, user's email address), email_confirmed_at (string, timestamp when email was confirmed, null if not confirmed), phone (string, user's phone number), phone_confirmed_at (string, timestamp when phone was confirmed, null if not confirmed), confirmed_at (string, timestamp when email or phone was confirmed, null if neither confirmed), last_sign_in_at (string, timestamp of last sign in), app_metadata (object, contains provider attribute indicating first sign-up provider and providers attribute listing providers available for login), user_metadata (object, defaults to first provider's identity data but can contain additional custom metadata; should not be used in security-sensitive contexts as it is editable by the user), identities (UserIdentity[], object array of identities linked to the user), created_at (string, timestamp when user was created), updated_at (string, timestamp when user was last updated), is_anonymous (boolean, true if user is anonymous).
Methods to retrieve user object
The user object can be retrieved using supabase.auth.getUser() or by retrieving a user object as an admin using supabase.auth.admin.getUserById().
User definition and Access Token
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 RLS policies.
Permanent users and identities
Permanent users are tied to a piece of Personally Identifiable Information (PII), such as an email address, a phone number, or a third-party identity. They can use these identities to sign back into their account after signing out.
Anonymous users definition and capabilities
Anonymous users are not tied to any identities. They have a user ID and a personalized Access Token, but they have no way of signing back in as the same user if they are signed out. Anonymous users use the authenticated role for database access, like permanent users.
Anonymous users use cases
Anonymous users are useful for e-commerce applications to create shopping carts before checkout, full-feature demos without collecting personal information, and temporary or throw-away accounts.
Difference between anonymous and unauthenticated users
Anonymous users have a user ID and use the authenticated role for database access. Unauthenticated or public users (anon role) are those who are not signed in at all and are not tied to any user ID.
User metadata stored in raw_user_meta_data column
User metadata is stored on the raw_user_meta_data column of the auth.users table. Metadata can be assigned to users on sign up via the options.data parameter.
Auth schema not exposed in auto-generated API
For security reasons, the Auth schema is not exposed in the auto-generated API. To access user data via API, you must create your own user tables in the public schema and protect them with Row Level Security.
Cannot delete users who own Supabase Storage objects
You cannot delete a user if they are the owner of any objects in Supabase Storage. An error will occur when trying to delete such a user. To resolve this, delete all the objects for that user or reassign ownership to another user.
Banning user is not a substitute for deletion
A temporary ban only blocks sign-in for its duration and does not revoke existing sessions. It is not a substitute for deleting the user when the goal is to remove account access.
Export users from auth.users table
Query the auth.users table via the SQL Editor to extract all users using: select * from auth.users; Results can then be exported as CSV.
Custom claims example structure
Custom claims are JSON attributes attached to a user and may include fields such as user_role (string), plan (string), user_level (number), group_name (string), joined_on (ISO 8601 timestamp), group_manager (boolean), and items (array of strings).
Auth Hook dashboard configuration
Enable the custom access token auth hook in the Supabase dashboard by navigating to Authentication > Hooks (Beta) and selecting the appropriate Postgres function from the dropdown menu.
Auth audit logs automatically capture all authentication events
Supabase auth audit logs automatically capture all authentication events. Events logged include user signups and logins, password changes and resets, email verification events, and token refresh and logout events.