Auto-refreshing of tokens can fail and never restart again

[vojtabohm]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

When the refresh of a token fails (e.g. the app went into background or the refresh API call fails for plethora of reasons) the library silently fails and never refreshes the token again.

_ = try? await refreshSession(refreshedSession.refreshToken) (in the scheduleNextTokenRefresh function).

To Reproduce

Set your phone into airplane mode, wait for refresh to fail. It will never refresh again since scheduleNextTokenRefresh is called recursively from refreshSession that can fail, it will be stopped.

If you follow the docs recommendation

It's best practice and highly recommended to extract the access token (JWT) and store it in memory for further use in your application.

basically something like this:

func authToken() async throws -> String {
        if let token = _authToken {
            return token
        }
        
        return try await supabase.auth.session.accessToken
    }

... inside a task ...

for await (event, session) in supabase.auth.authStateChanges {
                print("Auth change:", event, session)
                switch event {
                case .initialSession, .signedIn, .tokenRefreshed:
                    // Store _authToken in memory, as per Supabase's docs recommendation
                    _authToken = session?.accessToken

... some other code ...

and you rely on authStateChanges to always give you a token, then you can run into issue of token failing to refresh and you're forever stuck with the old one.

Expected behavior

It would be great to incorporate some sort of retry mechanism. I worked around this with storing the entire session, not just the token and manually refreshing if it's expired.

func authToken() async throws -> String {
        if let session = _authSession, !session.isExpired {
            return session.accessToken
        } else {
            let newSession = try await supabase.auth.session
            _authSession = newSession
            
            return newSession.accessToken
        }
    }

I think this is a good work-around so if a retry mechanism is too complicated (which is understandable), perhaps update of the docs could be in order.

[AlanDuong07]

We are also experiencing a ridiculous amount of people that log into our app, use it every day, but on the third day or so, their session is completely gone. This is breaking their ability to even utilize our app.

We rely on this code that initializes on app start. We then utilize the authJWT to authenticate and identify our users on every backend API call. But the session becomes nil, and thus everything is set to nil.

for await (event, session) in await supabase.auth.authStateChanges {
self.authJWT = session?.accessToken
self.supabaseUserId = session?.user.id.uuidString
self.email = session?.user.email ?? ""
}

Please, can we have eyes on this issue? This is a high severity issue.

[grdsdev]

Hi, thanks for reporting this issue, I'll be working on it ASAP.

In the meanwhile, if anyone has a fix for it, feel free to PR it and I'll gladly review it.

[grdsdev]

Hi @vojtabohm and @AlanDuong07 could you confirm which version of the library are you using?

[grdsdev]

@vojtabohm I wasn't able to reproduce by using airplane mode and using latest version of the library, please note that there are no scheduleNextTokenRefresh in the last version, so I assume you're using an outdated version.

[AlanDuong07]

Hi @vojtabohm and @AlanDuong07 could you confirm which version of the library are you using?

Hi, we were on version 2.20.4 I believe. I have since upgraded to the latest version. Though looking through the update notes, I don't see many changes regarding dropped sessions. I will let you know if the problem magically goes away with the latest update.

Could I please get help with whether my use of Supabase Swift is correct @grdsdev?

Only with the usual initialization code for Supabase Swift SDK, I initialize on app launch, this code that listens to auth state:

 for await (event, session) in await supabase.auth.authStateChanges {
      if let session = session {
          self.authJWT = session.accessToken // I save the authJWT here.
          self.supabaseUserId = session.user.id.uuidString
          self.email = session.user.email ?? ""
       }
}

On user sign in with apple / google, I use
try await supabase.auth.signInWithIdToken()

That should trigger the authStateChanges listener to have a session, so I can save the authJWT in memory as the docs recommend. I reassign the authJWT when new session data comes in.

Yet after a few days or so, users have an auth JWT of nil! The entire session, in fact, becomes undefined, because both "self.authJWT and self.supabaseUserId" become nil and stay nil. How could this be happening?

This is the only code I use to handle Supabase Auth. Isn't it that simple, or am I missing something?

[grdsdev]

Your usage of the SDK seems fine, could you attach a logger on initialization and send logs over?

You can use the example:

          struct AppLogger: SupabaseLogger {
            func log(message: SupabaseLogMessage) {
              print(message.description)
            }
          }

          let client = SupabaseClient(
            supabaseURL: URL(string: "https://xyzcompany.supabase.co")!,
            supabaseKey: "public-anon-key",
            options: SupabaseClientOptions(
              global: SupabaseClientOptions.GlobalOptions(
                logger: AppLogger()
              )
            )
          )

[grdsdev]

Hi all, any updates on this? Is it still an issue for you?

[vojtabohm]

I already used the workaround I mentioned in the original post. This way I am sure I have a fresh session whenever I need it. It was faster than debugging this for multiple days on GitHub. Feel free to close this. I more or less created it for people who might run into the same issue.

[grdsdev]

Closing due lack of updates.

[vojtabohm]

I know this is closed but I wanted to follow up here with a few important updates @grdsdev .

I’ve run into deeper issues that still point to a broken assumption in the SDK’s session lifecycle.

What's still broken

There are still valid cases where the initial session becomes nil, despite the user being signed in and having a refresh token on a local, expired session. Refreshing manually raises "Refresh token not found" AuthError. This has now happened:

• To me personally
• And during Apple’s App Store review

So this is not an edge case — it’s clearly hitting real users in production environments.

Supabase SDK version: 2.15.3

What I’ve done

As mentioned I no longer rely solely on authStateChanges or Supabase’s internal session refresh logic. I rewrote my session/token access logic to manually refresh expired sessions every time I need the token:

func authToken() async throws -> String {
    if let session = _authSession, !session.isExpired {
        return session.accessToken
    } else {
        let newSession = try await supabase.auth.session
        _authSession = newSession
        return newSession.accessToken
    }
}

This works well most of the time — but I still occasionally get caught in a race condition during app startup, where:

• Supabase is still processing .initialSession
• My app tries to use the token
• The refresh doesn't happen fast enough
• Or fails silently
• And I’m left with an expired session and initialSession = nil

I’ve now added a local initialSessionReady flag to defer all token usage until Supabase has fully booted and attempted its refresh — but this is clearly a workaround.

What should happen

In an ideal world:

• Sessions should never expire if the refresh token is present
• The SDK should retry failed refreshes (e.g. after coming back online)
• The client should not emit .initialSession = nil unless it is 100% certain the session is irrecoverable
• Or at the very least, the SDK should offer a clear hook or signal when the session refresh has either succeeded or truly failed

What I suggest

If retry logic is too complex to handle internally, at minimum:

• Please document this behavior clearly (that .authStateChanges can silently fail forever)
• Offer a built-in way to check if the refresh attempt is still pending
• Or expose a sessionLoadStatus enum (e.g. .loading, .ready, .failed) to avoid needing fragile workarounds

[vojtabohm]

I updated the SDK to the latest 2.26.1 now (I don't know if anything changed between 2.15.3 and it regarding auth). Will test and let you know further findings. Currently, there is still a possibility of users being signed out more than they should be (ideally never).

[grdsdev]

Hi @vojtabohm thanks for comprehensive feedback on this issue.

I'll evaluate all the suggestions and come up with a solution for the SDK.

Thanks.

[idec]

Hi @vojtabohm, @grdsdev,

We've been experiencing a similar issue where the SDK seem to be unable to restore the session of anonymous users after an app update. We haven't found an exact way to reproduce this but it's been happening every now and then for us always after an app update or after uninstalling and re-installing the app.

Could this be related? Was your issue finally solved with the latest SDK updates @vojtabohm?

Thank you.