feat: add Supabase Auth identifier to OAuth redirect URLs

[cemalkilic]

Summary

Adds a Supabase Auth identifier (sb) to URL fragments in all OAuth redirect responses to help clients distinguish Supabase Auth redirects from third-party OAuth flows.

Problem

auth-js GoTrueClient currently intercepts all URL fragments containing access_token, including those from non-Supabase OAuth providers. This causes unintended logouts and authentication issues when users have other OAuth flows in their applications.

Related issue: supabase/supabase-js#1697

Solution

Added an empty sb parameter to the URL fragment in all redirect responses:

• Success redirects with tokens (via AsRedirectURL)
• Error redirects in OAuth callbacks (supabase-js has a __isAuthError, but adding it for error to be fault-tolerant, and non-supabase-sdk cases)
• Error redirects in verification flows
• Message redirects in verification flows

Example redirect URL:
https://example.com/callback#access_token=xxx&refresh_token=yyy&expires_in=3600&sb

Clients can now check for the presence of sb in the fragment to confirm the redirect originated from Supabase Auth.

[coveralls]

Pull Request Test Coverage Report for Build 20268680017

Details

• 6 of 6 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.009%) to 68.536%

---

Totals
Change from base Build 20136212429:	0.009%
Covered Lines:	14688
Relevant Lines:	21431

---

💛 - Coveralls

[bnjmnt4n]

Interesting use case. I guess it is uncommon for the same URL to be used as the redirect URL for multiple auth servers in different OAuth flows, which is why this isn’t really described in the spec?

[mandarini]

@cemalkilic the security bot on the supabase-js repo has some interesting takes:
supabase/supabase-js#1959 (comment)

For production security, consider implementing cryptographic validation using a state token or nonce similar to the PKCE flow, which would require coordination with the Auth server implementation (https://github.com/supabase/auth/pull/2299).

I think, the way we have talked about it, is that the sb parameter is for disambiguation. Users requiring extra protection should use flowType: 'pkce'. Adding this sort of validation to implicit flow would be out of scope in this case.