Bug: v4.15.3 isSafeRedirectUri check breaks native app (custom URI scheme) OIDC redirects

✅Solved☁️Zitadel Cloud🔗OIDC❓Question🪲Bugs

Affected version: v4.15.3 (commit 038265925038265925, "guard defaultRedirectUri in OIDC/SAML FailedPrecondition paths")

Symptoms:
- Native mobile apps (Flutter/Android/iOS) using a custom URI scheme as redirect_uriredirect_uri (e.g. com.example.app://callbackcom.example.app://callback) see an "Unsafe redirect URI was blocked" warning banner after password submission in the Login UI.
- Pressing Continue a second time shows "You are signed in" within the browser but never redirects back to the native app — the auth code is never delivered.
- Was working correctly on v4.15.2 and earlier with no config changes on our side.

Root cause (traced in your source):

apps/login/src/lib/client-utils.tsapps/login/src/lib/client-utils.ts — isSafeRedirectUriisSafeRedirectUri:

const parsedUri = new URL(uri);
if (parsedUri.protocol !== "http:" && parsedUri.protocol !== "https:") {
  return false; // blocks all custom URI schemes
}

const parsedUri = new URL(uri);
if (parsedUri.protocol !== "http:" && parsedUri.protocol !== "https:") {
  return false; // blocks all custom URI schemes
}

handleServerActionResponsehandleServerActionResponse now passes every post-login redirect through this check:

if (isSafeRedirectUri(response.redirect)) {
  router.push(response.redirect);
} else {
  setError("Unsafe redirect URI was blocked"); // triggered for custom schemes
}

if (isSafeRedirectUri(response.redirect)) {
  router.push(response.redirect);
} else {
  setError("Unsafe redirect URI was blocked"); // triggered for custom schemes
}

Custom URI schemes (e.g. com.example.app:com.example.app:) have a protocolprotocol that is neither http:http: nor https:https:, so they are unconditionally blocked — even though the OIDC server already validated the redirect_uriredirect_uri against the registered allow-list before this client-side check runs.

Why this is incorrect:
The redirect URI was already validated by the OIDC backend against the app's registered allow-list. Applying a second client-side protocol check that rejects non-http/https schemes double-validates in a way that breaks RFC 8252 native app flows, which explicitly define custom URI schemes as the standard redirect mechanism for mobile/desktop apps.

References:
- RFC 8252 (OAuth 2.0 for Native Apps), Section 7.1 — Private-Use URI Scheme Redirection
- Commit 038265925038265925 — v4.15.3

Bug: v4.15.3 isSafeRedirectUri check breaks native app (custom URI scheme) OIDC redirects

✅Solved☁️Zitadel Cloud🔗OIDC❓Question🪲Bugs

const parsedUri = new URL(uri);
if (parsedUri.protocol !== "http:" && parsedUri.protocol !== "https:") {
  return false; // blocks all custom URI schemes
}

const parsedUri = new URL(uri);
if (parsedUri.protocol !== "http:" && parsedUri.protocol !== "https:") {
  return false; // blocks all custom URI schemes
}

handleServerActionResponsehandleServerActionResponse now passes every post-login redirect through this check:

if (isSafeRedirectUri(response.redirect)) {
  router.push(response.redirect);
} else {
  setError("Unsafe redirect URI was blocked"); // triggered for custom schemes
}

if (isSafeRedirectUri(response.redirect)) {
  router.push(response.redirect);
} else {
  setError("Unsafe redirect URI was blocked"); // triggered for custom schemes
}

Bug: v4.15.3 isSafeRedirectUri check breaks native app (custom URI scheme) OIDC redirects

Bug: v4.15.3 isSafeRedirectUri check breaks native app (custom URI scheme) OIDC redirects

Continue the conversation

ZITADEL

Continue the conversation

ZITADEL

Similar Threads