Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Supabase Auth, a user is the account, an identity is a sign-in method linked to that account, and a session is the authentication state that lets a browser act as that user. One user can have multiple identities, while each active session is represented by an access-token and refresh-token pair.
These records live in or relate to the Auth system backed by your project’s Postgres database. Your application can reference the Auth user ID, but profile data and authorization rules should be designed separately.
How users, identities, and sessions differ
| Concept | What it represents | Relationship | Security role |
|---|---|---|---|
| User | An Auth-managed account in auth.users. |
One account can be linked to multiple identities and can have browser sessions. | Provides the canonical user ID that application tables can reference. |
| Identity | A sign-in method associated with a user, such as email, phone, OAuth, or SAML. | Multiple identities may belong to one user. An anonymous user has no identity until one is linked. | Describes how the user authenticates; it is not itself the browser’s session credential. |
| Session | Authentication state binding a verified identity to a browser. | Represented by an access token and a refresh token. | Provides credentials for authenticated requests; the access token carries claims used for authorization. |
Supabase defines an identity as “an authentication method associated with a user.” The distinction matters when a person signs in through more than one provider: the sign-in methods are identities, while the Auth account they are linked to is the user. See Supabase’s identity guide.
Recommended Free Tools
What is stored in auth.users?
auth.users is the Auth-managed account record and the usual canonical identifier for connecting application data to a user. Supabase Auth is backed by the project’s Postgres database, and application tables can reference the Auth user ID with a foreign key where appropriate. Supabase’s Auth overview explains how Auth data relates to the project database.
#1 Best Overall
Do not treat the Auth schema as a general-purpose profile database. Put application-specific profile fields in a table your application owns, keyed by the Auth user ID. This gives you room to define the data and access rules your application needs without turning the Auth account record into a catch-all. Supabase’s Auth0 migration guide recommends an application table for larger amounts of user-specific metadata.
What does auth.identities represent?
An identity records a way a user can authenticate. Supabase documents identity types including email, phone, OAuth, and SAML. A user may have more than one identity, so an account and a sign-in method are not interchangeable.
Rank #2
An identity object includes an identity ID, linked user ID, provider name and provider identifier, provider-specific identity data, and timestamps. For email and phone identities, the provider identifier is the user’s ID from auth.users; OAuth and SAML identity data includes information from the external provider. Anonymous accounts begin without an identity; an identity is present after one is linked.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →How a browser session uses tokens
Supabase describes a session as the concept that binds a verified identity to a browser. The session is represented by two credentials:
- Access token: a JWT used to authenticate requests. Supabase’s glossary describes access tokens as short-lived, usually no more than one hour.
- Refresh token: a randomly generated string used as part of maintaining or refreshing the session.
The pair represents the browser session, which Supabase describes as usually long-lived. The exact lifetime and refresh behavior depend on the project’s configuration and implementation. See the Supabase Auth glossary.
Claims connect a token to a user and session
The access token’s JWT claims provide identity and authorization context. Required claims include sub, the user UUID; session_id, the unique session identifier; role; aal; and the issuer, audience, expiration, and issue time. The claim reference also lists email, phone, and is_anonymous. Optional context can include app_metadata, user_metadata, and amr. Use the JWT claims reference for the field definitions.
Applications should validate the JWT signature and relevant claims—including expiration, issuer, and audience—before trusting token data. Never put a service-role token in client-side code.
Server-side rendering changes where tokens are stored
In server-side rendering (SSR), server code cannot read a browser’s local storage. Supabase’s SSR advanced guide calls for secure cookie storage and recommends the PKCE flow for SSR; it states that @supabase/ssr initializes clients to use PKCE by default. Follow the current package documentation for implementation details, since package behavior can change.
Where profile data and metadata belong
Supabase distinguishes two JSONB metadata columns described in its Auth0 migration guide:
raw_user_meta_datacontains user-editable metadata. Do not rely on it as a trusted source for authorization decisions.raw_app_meta_datais application-controlled and should not be user-editable.
Both kinds of metadata are included in access tokens, so keep them lean. For substantial profile information or application data, use an application-owned table instead of adding excessive data to token metadata.
How RLS uses Auth context
Row-level security (RLS) policies let Postgres decide which rows a client can access using authenticated context. Supabase integrates Auth helper functions such as auth.uid() and auth.jwt() into policy conditions. A policy can, for example, limit access to rows associated with the authenticated user ID. The RLS guide explains the feature and its Auth integration.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Take care when exposing Auth data through views. Supabase warns that a view can expose personal information if it does not respect the underlying RLS protections; security-invoker views are one approach for respecting those policies. Avoid exposing auth.users through an ordinary public view without understanding its security behavior. See the Auth users exposure advisory.
Quick Recap
A practical way to model the relationship
- Use the Auth user ID as the account reference. Create application-owned tables for profile and product data, and relate rows to the Auth user ID where appropriate.
- Keep sign-in methods conceptually separate. A user may link multiple identities; do not model each provider login as a separate application account unless that is the deliberate behavior your product needs.
- Authorize database access with RLS. Write policies around the authenticated user and the specific data relationship, rather than trusting user-editable metadata.
- Treat tokens as credentials. Validate claims on trusted server paths, keep privileged service credentials off clients, and use the current SSR guidance for cookie-based token handling.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
