What is Supabase Auth and how do its users and sessions work?
Published on 2026-10-20 by frfrand
Supabase Auth explicado: login, registro, JWT, sesiones, refresh token, recuperación de cuenta y relación con las políticas RLS.
Supabase Auth is the Supabase service that helps register users, verify their identity, and maintain sessions within an application. It allows implementing methods such as email and password, magic links, and certain external providers without writing the entire authentication mechanism from scratch.
But be careful: authenticating is not the same as authorizing. Knowing who a person is does not mean they have permission to query all the data in your project.
The library example
Imagine a library with membership cards. Showing the card allows staff to know who you are, but that does not mean you can open the administration cabinet or take a book reserved for someone else.
In an application, something similar happens: login identifies the user; authorization rules decide what data and operations they can access.
Supabase Auth provides pieces for the first part and integrates with PostgreSQL capabilities, such as RLS, to support the second.
What happens when someone logs in?
In a typical flow, the client sends credentials to an authentication service. If they are verified, it can receive session data and tokens that it will use in subsequent requests.
Supabase uses JWT, or JSON Web Tokens, to represent certain identity and session information. A signed JWT allows the receiver to verify its validity following the system's rules.
The token should not be confused with a password nor with a guarantee that any request is authorized. Its issuer, validity, signature, and expected properties must also be validated.
What is an access token?
It is a credential that the client uses for a limited period to demonstrate that it has a valid session.
When an application makes a request to Supabase services, libraries can manage sending the corresponding token.
The server or database uses that identity within its authorization mechanisms. For example, an RLS policy may allow the person to consult only their own reservations.
And the refresh token?
It is used to request new access credentials without asking the user for their password on each operation.
The duration, renewal, and revocation of sessions depend on the configuration. It is not advisable to copy values from an old guide without reviewing the documentation of the current version.
It is also necessary to decide what happens when logging out, changing the password, or detecting a compromised device.
Where are tokens stored?
It depends on the architecture. A browser application, a mobile app, and a traditional backend do not necessarily have to manage sessions in the same way.
Storing credentials in places accessible to JavaScript involves considerations against XSS attacks. Using cookies also requires studying attributes, origin policies, and protection against certain unwanted requests.
The important thing is to choose a recommended pattern for your framework and understand its risks, not move tokens from one place to another because a tutorial said it is "more secure".
What is a magic link?
Instead of entering a traditional password, the user receives an access link sent to their email. The system validates that link under defined conditions.
It is convenient, but security depends heavily on the email account and on how links are protected and expired. If someone controls the person's email, they may try to take advantage of recovery or access methods.
Does Supabase Auth replace all user logic?
Not necessarily. It can manage identity and sessions, while your application maintains profiles, preferences, commercial roles, and other tables.
It is not advisable to use the authentication system's internal tables directly as if they were your complete business model. Follow the supported mechanisms to link identities with application data.
How does RLS intervene?
When a request arrives with a verified identity, PostgreSQL can apply policies that limit visible or modifiable rows.
A read policy does not automatically protect all operations. SQL permissions and privileged keys must also be reviewed. In particular, never publish administrative secrets on the frontend.
When is it worth using Supabase Auth?
It is useful if your application already works with the Supabase ecosystem and needs login, sessions, and data access permissions.
If you have a complete backend with a consolidated user system, it may be better to integrate that system instead of maintaining two unnecessary identity sources.
And in ArduMaker?
If you host your own backend or PostgreSQL databases on ArduMaker VPS, you can implement authentication using tools appropriate for your architecture. Supabase Auth is a different external option, not a function that should be assumed available by default in any PostgreSQL.
In summary: Supabase Auth solves much of the authentication; your application still needs authorization, secure sessions, and correct permission design.
Sources: Supabase Auth Documentation · Supabase Sessions · JWT in Supabase.