setSession doesnt work

[furkananter]

Hi, We have a switch account feature inside react native cli app. Normally until today it was working correctly but this morning it has broken.
I am getting this error when i try to setSession my user access token and refresh token: ERROR Error signing out [AuthApiError: Session from session_id claim in JWT does not exist]

[knielsen24]

I am having the same issue and error message
"Error during logout: [AuthApiError: Session from session_id claim in JWT does not exist]". First I discovered the our reset password flow is not longer working, and then discovered the signoout functionality is no longer working as well.

[furkananter]

This is a bad situation. We are having sort of same issues as well as you. I think it is related with some new changes on supabase/auth code. I think Supabase could tell us a new updates about Auth code then we can be ready for updates. This is effecting directly our production applications.

[knielsen24]

UPDATE

Our reset password flow is working now and was related to another issue.

Regarding the logout error with AuthApiError, I am getting inconsistent behavior. The sign-out would work, then error, work, and then error. As of the moment it is working.

[kangmingtay]

@knielsen24 have you tried upgrading your version of supabase-js? we made a fix for this in the client library here awhile back so even if you get this error, the signout method will still work and remove the session locally

[GaryAustin1]

@knielsen24 This was discussed in Discord yesterday with the OP.
It appears this change is what caused the issue. supabase/auth#1538
They believe they are no correctly showing an error for something that in the Discord case maybe should not have been working. I don't think a resolution was reached.

https://discord.com/channels/839993398554656828/1235896967754682478

[knielsen24]

@GaryAustin1 Thanks for the reply. How do I join the Discord channel?

[GaryAustin1]

https://discord.com/invite/R7bSpeBSJE

[Olow304]

session_id claim in JWT does not exist

This is effecting my production app. Any updates?

[GaryAustin1]

Did you look at the above links?
There was a change made to fix error handling and it appears users are being impacted by the change.
No one has generated a response to the PR or an issue in supabase/auth issues that I see.
Not clear Supabase knows this is impacting anyone.
My understanding from the Discord is that the use case was not valid and now the error catches it... but at least 3 of you are impacted so either a common thing to do, or the PR has broken something else.

[Revarh]

Hey,
Same error here in production and on local machine : Session from session_id claim in JWT does not exist
Happened last Friday... Sometimes if I managed to empty my cache it's working again, but not always...

[joshuadunning]

We are also experiencing this error in production. Looking for possible workarounds

[joshuadunning]

I have a solution. I don't know if our users are logged out prematurely, or if sessions are being killed on another login.

But I think based on the PR mentioned above, I have a solution for us.

Previously, this error was not caught properly and was therefore falling back to a 401 unauthorized error. At this point we redirect our users to login. With the change from the PR, it appear that it now returns a 403 forbidden which is treated as an authorization error, not authentication. I believe providing my own wrapper around setSession to translate this specific 403 to a 401 for our users will be a viable workaround.

Honestly, I think the way setSession is used in our case (to create authenticated supabase sessions on our api server) warrants this error to return a 401. Perhaps there are other lines of thinking on why this should be a 403 instead.

Open to any feedback if I've missed something.

[Revarh]

You maybe onto something. I remember trying to log in, sometimes a couple times, and having to do it again because redirected.
The think is, how do change that 403 to a 401 ? I tried to catch the error in my authProvider but everything was fired way before...

[ColeTownsend]

In our use case, we update the user using the auth.admin.updateUserById. This works fine, but seems to trigger a change that deletes the corresponding session.

[joshuadunning]

Unfortunately I determine it by the error message right now. This is how I am throwing an error since the error comes back as a value.

const { data, error } = await s.auth.getUser(jwt);
if (error) {
if (
error.status === 401 ||
error.message.includes(
'Session from session_id claim in JWT does not exist'
)
) {
throw err(401, 'Unauthorized');
}
......
}

[daniel-krastev]

Another instance of AuthApiError: Session from session_id claim in JWT does not exist here as well, on log out.

[kangmingtay]

@daniel-krastev have you tried upgrading your version of supabase-js? we made a fix for this in the client library supabase/auth-js#894 awhile back so even if you get this error, the signout method will still work and remove the session locally

[alignbenpersitz]

@kangmingtay I am encountering this same error when I update my password on serverside. The session gets reset, and then my session is invalid. Caling the signout method does not fix it and I have to go into localstorage and delete the values stored there to not e stuck in a 403 loop. I am on the most recent version of supabase/auth-js.

[monicakh]

This error is returned when we detect that the session_id claim in the access token doesn't exist in the auth.sessions table. It was introduced in this PR (supabase/auth#1538) because we realised that we were returning the wrong error when the session is missing. Before this PR was merged, the sign out API would return a panic and fail silently, returning a 5xx error to the client which can't be handled.

You can fix this by doing either one of these options:

• Manually ignore 403s returned from signOut and just clear the local session stored on the browser.
• Upgrade to supabase-js v2.43.1 which contains the changes to ignore 403s returned by the signOut method

[ColeTownsend]

In our use case, we update the user using the auth.admin.updateUserById. This works fine, but seems to trigger a change that deletes the corresponding session.

We're doing

await this.supabaseAdmin.auth.admin.updateUserById(payload.uuid, {
        email_confirm: true,
        email: payload.email,
        password: payload.password,
        user_metadata: {
          first_name: payload.firstName,
          last_name: payload.lastName || '',
          new_api: true,
        },
      });

Via an endpoint, which totally works. I see the user's email and password set.

However a subsequent call to supabase to simply fetch the public user, using the same token, returns Session from session_id claim in JWT does not exist when we run setSession.

When I checked the auth_audit_logs I saw

{"action":"user_modified","actor_id":"00000000-0000-0000-0000-000000000000","actor_username":"service_role","actor_via_sso":false,"log_type":"user","traits":{"user_email":"test.otp.session@yahoo.com","user_id":"9db63345-b35a-42f0-8045-3ce14e18fe61","user_phone":"1XXXXXXX"}}

And when checking the session table for any sessions associated with 9db63345-b35a-42f0-8045-3ce14e18fe61, there was nothing.

[kangmingtay]

hey @haydn and @ColeTownsend, this happens because the admin update user method will automatically revoke all existing sessions on a password update for security reasons

is there a reason why you'd want to keep the user's session despite performing a password update?

[maisterr]

@kangmingtay, this becomes problematic when updating the password directly on the platform, requiring both the old and new passwords. Although less secure than email updates, some sites still use this method. After updating the password, the session is revoked, and the user needs to relogin.

[kangmingtay]

this becomes problematic when updating the password directly on the platform, requiring both the old and new passwords

@maisterr i'm not too sure what you're referring to here? that doesn't seem to use the admin user update method. The regular updateUser method is unaffected by this

[ColeTownsend]

hey @haydn and @ColeTownsend, this happens because the admin update user method will automatically revoke all existing sessions on a password update for security reasons

is there a reason why you'd want to keep the user's session despite performing a password update?

In order to add a user password in addition to the user authenticating via phone, we do this. We set a random password and then they can reset it as needed.

[haydn]

Sorry, I should've linked this here earlier:

supabase/auth#1579

We were using the admin user update to set the password for a new user that was invited into the app using a OTP. Our whole flow could probably do with a rework — there have been a lot of changes to Supabase since we first implemented this.

The workaround described in that issue was fine for us, it is was just a bit annoying for this to suddenly break in our production app.

[ahnsv]

Anyone having the same issue now?
We use two supabase accounts; one is having the same issue when we use setSession, and the other is not.

Weird part is that only new created accounts are failing to set session. Old accounts are working as expected.

[haydn]

The most recent release had some changes that sound like they could be related:

https://github.com/supabase/auth-js/releases/tag/v2.64.3

One of your projects might've be using that release and the other is on an older version?

[jparismorgan]

I'm also seeing this in the following scenario:

• From a web browser, iser signs in with const {error} = await supabase.auth.signInWithOAuth({provider, options: {redirectTo}}). I then call const {data: {user}, error} = await supabase.auth.getUser() on the server and use that check to verify I can make an API call. This works fine.
• From an iOS app, user signs in using a jwt generated with try client.auth.getOAuthSignInURL(provider: .github, redirectTo: callbackURL) in Swift. I tehn call const {data: {user}, error} = await supabase.auth.getUser(jwt) on the server and use that check to verify I can make an API call. This works fine.
• From a web browser, user comes back to the website and calls const {data: {user}, error} = await supabase.auth.getUser() on the server. I then get AuthApiError: Session from session_id claim in JWT does not exist.

So it seems that somehow generating a JWT in Swift and using it to fetch data from the server invalidates the user's other sessions on web. Note that Enforce single session per user is false, so it's not that.

[kamajus3]

have you tried update your supabase version?

it worked for me.