OAuth callback URL incorrectly prefixed with https://kick.com after third-party login (Apple / Google)

[FZK802399]

Describe the bug
When integrating Kick's OAuth flow using ASWebAuthenticationSession on iOS, the redirect URL after completing third-party login (Apple Sign In or Google Sign In) is malformed — Kick's server incorrectly prepends
   https://kick.com/ to the next redirect URL, causing the OAuth flow to fail.
To Reproduce

1. Initiate Kick OAuth flow via ASWebAuthenticationSession with the authorization URL:
     https://id.kick.com/oauth/authorize?client_id=...&redirect_uri=...
     2. On the Kick login page, select "Continue with Apple" or "Continue with Google"
     3. Complete the third-party authentication
     4. Observe the redirect URL returned by Kick
   Expected behavior
   Kick should redirect back to:
     https://id.kick.com/oauth/authorize?client_id=...&redirect_uri=...

  Actual Behavior

  Kick redirects to a malformed URL:
  https://kick.comhttps//id.kick.com/oauth/authorize?client_id=...&redirect_uri=...

  Two issues are present:
  - https://kick.com/ is incorrectly prepended to the full redirect URL
  - The https:// in the original URL loses its colon, becoming https//
Impact

• Affects all third-party login providers (Apple, Google, etc.)
    - OAuth flow cannot complete — ASWebAuthenticationSession never receives the callback
    - All third-party developers integrating Kick OAuth on iOS are affected
    -
  Environment
• Platform: iOS (ASWebAuthenticationSession)
    - Kick OAuth endpoint: https://id.kick.com/oauth/authorize
    - Reproducible with both Apple Sign In and Google Sign In

[Santiagovillalobos-12]

We're experiencing the exact same issue in a production OAuth integration with Kick.

Environment:

Desktop browsers (Chrome + Brave)
OAuth Authorization Code Flow with PKCE
Server-side redirect (HTTP 302)
Custom backend (Go)
SPA frontend (Vue)

The generated authorization URL is valid and correctly formed:

https://id.kick.com/oauth/authorize?client_id=...&redirect_uri=...

We verified:

redirect_uri matches exactly the one configured in the Kick developer portal
URL is correctly encoded
No malformed URLs exist in our frontend/backend code
The issue still occurs even after removing all JavaScript redirects/interstitials and using pure HTTP redirects

However, after authenticating through Google login inside Kick, the browser is redirected to a malformed URL like:

https://kick.comhttps//id.kick.com/oauth/authorize?...

Notice:

https://kick.com is incorrectly prepended
the original https:// loses the colon and becomes https//

This appears to happen during Kick's internal redirect/check-cookie flow, not in application code.

We were able to reproduce this consistently in Chrome and Brave on desktop, so this does not seem limited to iOS / ASWebAuthenticationSession.

Based on network traces, the issue may be related to Kick's internal continue= redirect handling after third-party authentication.

This is currently breaking OAuth login flows for external applications.