Authentication persistence in Supabase

[hyperknot]

Hi, I'd like to ask for some clarification about the authentication behaviour and to document exactly how does state persistence works in Supabase. I'd really like to choose Supabase over Firebase for a new project but this honestly feels missing from documentation and from general attention. I understand that there are fantastic new features being shipped every month, but please give some attention to the core Auth functionality.

I believe what people want is users to never be logged out on a website which uses Supabase. This has been the standard behaviour across industry (e.g. Facebook etc. would panic if their users are logged out automatically). Firebase actually has a page which documents fine grained controls over this behaviour.

It seems a lot of users are confused about this here, there are dozens of discussions popping up at regular intervals about "why are my users being logged out", "how to make sure no one ever gets logged out automatically", etc.

Also, this "JWT expiry limit" section couldn't be more confusing, almost everyone believes that this means how long are users logged in, and set it to 1 week and worry that even one week is too little.

---

My questions (very basic client side JS scenario, tested on react-user-management example).

1. What is the point of the 2 cookies: "sb-refresh-token" and "sb-access-token".

• If I delete them the app continues working perfectly from localStorage. What is the point of the cookies?
• The expiry time on both of them is 1 day. Why?

2. localStorage contains both of these values inside but it contains two expires_ values, 1 hour by default. What does this mean, what happens after it expires? localStorage never gets deleted by the JS lib (I hope) right? I mean can I conclude that refresh_token is forever lived on the client side?

3. What happens to the auth.refresh_tokens table? This has to be cleaned-up from time to time, I guess based on the "updated_at" column. But I couldn't find anything in the documentation or settings regarding this. This should be the most important information on the Auth control panel. Much more important than the "JWT expiry limit" field, which just confuses people.

4. Finally, when using axios, etc. to make external API requests sending JWT tokens, what is the way to manually refresh the JWT token using the refresh token? I guess the code should be something like

1. Check if JWT is still valid
2. If not, manually refresh it
3. Do the request with the valid JWT token.

[hyperknot]

New question, in the official nextjs-ts-user-management example, the storage is different:

• localStorage is not used
• There is a single cookie, supabase-auth-token which stores a URL encoded JSON with the following format:
  [auth_token, refresh_token, null, null]

The expiry date is 1 year. It's on localhost domain, not on supabase.

Now this seems to be totally different behaviour compared to the simple react-user-management example. Can you tell me where is this specified? I'd like to know if the 1 year keeps growing when refreshes are run or its a fixed time counted from login (by setting the time of my computer it does seem to be growing).

[hyperknot]

OK, I'm step-by-step getting to the bottom of this.

• The default client @supabase/supabase-js puts everything in localStorage. This never expires.
• The auth-helpers-* libs use a custom storage which is an improved version. It stores everything in a cookie which has 1 year expiry date by default. I guess the point of this is that it works in Safari Private mode, where localStorage wouldn't.
• The Dashboard's "JWT expiry limit" has nothing to do with session expiration, it works with as little values as 5 sec. It's just a technical settings for finding a balance between faster revoking (lower values) <> better performance (higher values). The default of 3600 might be a bit on the high side, as it means if you want to revoke a token, you won't be able to do this for up-to 1 hour.
• The two sb- cookies on the supabase.co domain don't do anything (or at least I haven't figured out what they do). They are created when using Magic Link login.

Now the expiry time: When using the auth-helpers the users would have to visit a site at least once per year, to make sure they are not logged out. So at least 1 login per year => forever logged in. Very nice default behaviour here.

Now the only question left over, which is basically the most important question:

What happens to auth.sessions / refresh_tokens on the server?

• If these are cleaned up at regular intervals, when exactly and how can we control this? This would be pretty much the most important setting on the dashboard, much more important than the "JWT expiry limit".
• If these are not cleaned up then how do people use Supabase in production? I mean these tables would grow indefinitely with mostly useless leftover data. Over time, performance will degrade and you'll pay for this in storage costs.

Can someone from Supabase comment on this? I've spent a few hours debugging the client behaviour on my own, it'd be so nice if someone could shed some light on the server part.

[hf]

Hey @hyperknot, thanks for all your questions. We're a small team and it takes a while to get to discussions.

Regarding persistence:

• We use local storage with vanilla SupabaseJS or cookies for Auth Helpers because of the recent resurgence of server-side rendering frameworks.

Regarding session control:

• I absolutely agree about the JWT expiry limit setting! It's maybe too prominent, when in fact it's more of an advanced setting. We're going to be fixing this at some point.
• Sessions are indefinite at this time. Sessions coming from SSO will obey the SSO identity provider information (if present) about the duration of a session. We're thinking about adding a wide variety of session control features (maximum duration based, inactivity based, exclusive sessions) but we're working on other important aspects at this time. You can build features for this yourself though based off data in auth.sessions and auth.refresh_tokens tables.

Regarding sessions / refresh_token tables:

• Not cleaned up yet, there is an open PR for that which we hope to get in in the next few weeks.
• We use GoTrue in production and have not noticed any performance issues due to these tables being quite large.

[hf]

One additional note: random logouts should not be happening. They are often caused by edge cases not handled well when using SSR frameworks. Use the Auth Helpers so this never happens for you.

[diogeneshamilton]

This is really helpful, thank you for the writeup! I'm curious if this applies to webkit/iOS Safari as well? I think we may be subject to this privacy limitation (eg. someone comes back to our site after 8 days, they are logged out, but if they come back within 7 days they stay logged in). Is that the case or no?

[gary-lo]

I have users on iOS complaining about getting logged out regularly too wondering if it's related to this.