Metadata exposed in JWT access token
User metadata fields (raw_user_meta_data and raw_app_meta_data) are exposed in the user's access token JWT, so it is recommended not to store excessive metadata in these fields.
auth
381 notes in this subject, read out of this brain and free to use. This is page 7 of 7.
Update user metadata in Supabase
Both raw_user_meta_data and raw_app_meta_data can be updated using the admin updateUserById method. To allow users to update their own raw_user_meta_data, use the updateUser method.
Store large amounts of user metadata
For large amounts of user-specific metadata, create your own table in a private schema using user_id as a foreign key instead of storing excessive data in raw_user_meta_data or raw_app_meta_data fields.
Custom user ID during migration
Supabase Auth uses UUID V4 format for user IDs by default. If your UUID format is identical to UUID V4, you can specify a custom ID in the admin createUser method using the id parameter.
Specify custom ID example
Example code for specifying a custom UUID during user creation in Supabase Auth: ```ts const { data, error } = await supabase.auth.admin.createUser({ id: 'e7f5ae65-376e-4d05-a18c-10a91295727a', email: 'valid.email@supabase.io', }) ```
Supported password hashing algorithms
Supabase Auth supports bcrypt and Argon2 password hashes. Passwords are always stored hashed, never as plaintext.
Password storage location
Passwords in Supabase Auth are stored in the auth.users.encrypted_password column.
MFA migration limitations
Supabase Auth only supports time-based one-time passwords (TOTP). Users who have TOTP-based MFA factors in Auth0 may need to re-enroll using their choice of TOTP-based authenticator (e.g. 1Password, Google Authenticator). Obtain MFA secrets from Auth0 by opening a support ticket.
SAML SSO migration
For SAML Single Sign-On migration, customers may need to link their identity provider with Supabase Auth separately. Users should still be able to sign in normally after authenticating with their identity provider. For detailed information, refer to the SAML 2.0 guide or contact support.
Organizations migration not supported
Migrating Auth0 organizations to Supabase Auth is not currently supported.
Auth tokens and JWT secrets after platform to self-hosted restore
JWT secrets differ between platform and self-hosted instances. Existing tokens issued by the platform project will not be valid on the self-hosted instance. Users will need to re-authenticate after the restore because new JWT secrets must be generated for the self-hosted deployment.
Social auth provider configuration for self-hosted after restore
Social auth providers (Apple, Google, GitHub, etc.) must be configured in the self-hosted .env file after restore. Set the relevant GOTRUE_EXTERNAL_* variables according to the Auth repository README. Additionally, redirect URLs in OAuth provider consoles (Apple Developer, Google Cloud Console, etc.) must be updated to point to the self-hosted hostname instead of *.supabase.co.
SSO configuration is applied immediately
When you save SSO configuration changes in the Supabase dashboard, the new configuration is applied immediately. From that moment, any user with an email address matching one of the configured domains who visits the organization's sign-in URL will be routed through the SSO flow.
Registering SAML IdP with Auth admin API
Use the Auth admin API endpoint POST /auth/v1/admin/sso/providers to register a SAML IdP. The curl request requires Authorization and apikey headers with the SERVICE_ROLE_KEY. There are two methods to register: 1. **Inline metadata XML**: Provide the metadata directly in the request body: {"type": "saml", "metadata_xml": "<EntityDescriptor ...>...</EntityDescriptor>", "domains": ["example.com"]} 2. **Metadata URL**: Provide a metadata URL and optional attribute mapping: {"type": "saml", "metadata_url": "https://idp.example.com/saml/metadata", "domains": ["example.com"], "attribute_mapping": {"keys": {"email": {"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"}, "name": {"name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"}}}} When using metadata_url, the metadata_url must use HTTPS. Auth automatically fetches and caches the metadata, refreshing when stale. Both methods require specifying the "domains" field with the list of domains where the IdP will be used.
Recommended SSO enablement workflow
The recommended workflow for enabling SSO is: 1. Create or verify at least one non-SSO owner account exists (required for safety) 2. Configure your SSO provider following provider-specific guides 3. Start with auto-join disabled to test the configuration 4. Test SSO login with your own account 5. Verify attribute mappings are correct 6. Test with 2-3 additional users 7. Thoroughly test using the SSO Testing and Best Practices guide 8. Enable auto-join if desired 9. Test auto-join functionality thoroughly 10. Communicate SSO availability to your team 11. Invite users to the organization or let them auto-join on login
Vercel Marketplace automatic account linking
When Vercel users interact with Supabase through Vercel Marketplace, they are automatically assigned Supabase accounts. New users get a Supabase account linked to their primary email, while existing users have their Vercel and Supabase accounts linked.
Vercel Marketplace role assignment
The user who initiates creation of a Vercel Storage database is assigned the owner role in the new Supabase organization. Subsequent users are assigned roles based on their Vercel role: developer role for Vercel member role, and owner role for Vercel owner role. Role management is handled directly in the Vercel dashboard, and changes are synchronized with Supabase.
Vercel Marketplace non-Vercel user permissions
Non-Vercel users can be invited to a Supabase Organization created through Vercel Marketplace, but their permissions will not be synchronized with Vercel.
SAML SSO via REST API
Initiate SAML SSO via REST API by domain or provider ID. Endpoint: POST http://<your-domain>/auth/v1/sso Headers: - Content-Type: application/json - apikey: your-anon-key Request body (by domain): {"domain": "example.com", "skip_http_redirect": true} Request body (by provider ID): {"provider_id": "d3f5a1b2-...", "skip_http_redirect": true} Response: {"url": "https://idp.example.com/sso?SAMLRequest=..."}
Manage SAML providers via admin API
Manage SAML providers using the admin API. **Disable a provider without deleting:** ``` curl -X PUT 'http://<your-domain>/auth/v1/admin/sso/providers/{provider_id}' \ -H 'Authorization: Bearer your-service-role-key' \ -H 'Content-Type: application/json' \ -H 'apikey: your-service-role-key' \ -d '{"disabled": true}' ``` **Delete a provider:** ``` curl -X DELETE 'http://<your-domain>/auth/v1/admin/sso/providers/{provider_id}' \ -H 'Authorization: Bearer your-service-role-key' \ -H 'apikey: your-service-role-key' ``` Both operations require a valid service role key for authorization.
Multiple SSO providers per organization
Supabase supports multiple SSO providers within an organization for advanced use cases. Common scenarios include: - Multiple environments (development, staging, and production) - Different providers for different teams or business units - Gradual migration from one identity provider to another - Organizational transitions such as acquisitions - Testing purposes Refer to the Multiple SSO Providers guide for detailed configuration steps.