Handle 400 error from supabase.co/auth/v1/callback with a redirect to an error page

[rdinicut]

Bug report

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

Describe the bug

When signing in with social Auth, for example Azure it seems that the callback has a timeout and if the users waits to long to login the callback fails with {"code":400,"msg":"OAuth state is invalid: token is expired by ..."} This breaks the flow and it is a very bad UX. In my opinion the supabase callback should redirect with some timeout error in order for the application to handle this, for example tell the user to retry the flow.

To Reproduce

Steps to reproduce the behaviour, please provide code snippets or a repository:

1. go to https://supabase-vercel-integration.vercel.app/
2. Click on sign in with Google
3. When on the sign in Google page, go make a coffee(wait 10 min to be sure)
4. Come back
5. Finish the sing in
6. get the 400 error shown in JSON

Expected behaviour

FEATURE REQUEST: Redirect to an app url with a timeout error

System information

• OS: MacOs
• Browser : Chrome
• Version of supabase-js: ^2.22.0
• Version of Node.js: v18.16.0

[micahjon]

Happened to me today when debugging my sign-in-with-apple flow. Would be great if this was handled in a more user-friendly way, such as redirecting back to the app with an error message instead of just showing the user JSON.

[fzmorales]

I have the same issue with sign-in-with-google :(

[LHDi]

This shouldn't be the case, it's really frustrating to show the user a json response

[michaelraffin]

I also tried different clientID such as ios/android/expoClient, but still no luck.

[Sapessii]

same here, any update or fix? thanks

[leBolideur]

Same here with Github and Twitter/X Any updates?

[williamoverton]

Same issue with Google

[LeoCaprile]

Same with google, working in local

[encima]

@supabase/auth

[adbincpro]

Same issue with most of the social providers , does anyone came across this fix.

[encima]

For everyone commenting here, are you saying "same issue" as in you are experiencing a timeout after 10 mins? For authentication, the timeout is intentionally short (leaving an access request open and keeping it valid while getting a coffee is a risk)

If you are experiencing this after 10 or 20 seconds then it is an issue we can look into.

Otherwise, this seems like a feature-request to add an error page to redirect to if the authentication request has timed out but is not a bug. Let me know and I will update accordingly

[wefanz]

Hi @encima, thank you for your reply, the problem is not the access request expiration, but what happens after the expiration.

It’s correct to throw error but as stated by LHDi, the user will see a json response, it should be better to allow us to add a redirect url to the app with a custom message.

[encima]

Noted, thanks for clarifying. I will update this issue to reflect that.

[olee]

Exactly that. An authentication server should never return a json output like this, but instead redirect the error as part of the url back to the application like it happens for other oidc errors. I would also suggest classifying this as a bug instead of enhancment, as showing an error like that is against oidc standard and breaks login.

I'm also in the process of looking for a workaround for this with self-hosted supabase and currently I'm entertaining the idea of making kong recognize this type of url and redirect the user accordingly.

[ddx-510]

Same issue here, any update? Can have some error in callback so we can handle the error on our own.

[Maianki]

Landed into someting similar. Has anyone found any workaround would love to know, Thanks.

[kangmingtay]

hey everyone, yeah agreed that the UX isn't great for this so we'll be looking to improve it!

for a start, we can opt to redirect the user to the SITE_URL - we can't really redirect the user to the redirect url specified when you call signInWithOAuth because the referrer is stored in the oauth state, which is in the form of a JWT. If you're getting the error that the OAuth state is invalid (due to the token being expired), then we can't trust any data stored in the JWT.

let me know what yall think!