facebook login js: Error validating verification code. Please make sure your redirect_uri is identical to the one you used in the OAuth dialog request

by

Summary

A developer integrated Facebook Login for WhatsApp Embedded Signup but encounters error 36008 (“Error validating verification code. Please make sure your redirect_uri is identical…”) during the token exchange step. The root cause is a mismatch between the redirect_uri used implicitly by the client-side SDK (via the pre-configured “Valid OAuth Redirect URIs” in Meta App settings) and the one expected by the Graph API endpoint. Additionally, there is confusion between Authorization Code Flow (requires redirect_uri) and Client-Side Flow (does not). By strictly aligning the client-side flow with the correct API parameters, the issue is resolved.

Root Cause

The error stems from a strict security validation in Facebook’s OAuth 2.0 implementation. The code generated by FB.login() is cryptographically bound to the redirect_uri used during the authorization request.

  • Implicit vs. Explicit Redirect URI: When using FB.login() without an explicit redirect_uri parameter, the SDK defaults to the first URL listed in the Facebook App Dashboard > App Settings > Basic > Valid OAuth Redirect URIs. The subsequent call to GET /oauth/access_token must match this URI exactly, including the trailing slash and protocol.
  • Flow Mismatch: The developer is calling the /oauth/access_token endpoint (designed for the Authorization Code flow) while using the response_type: 'code' inside FB.login(). The JS SDK handles the redirect and code delivery internally (Client-Side Flow), making the redirect_uri parameter mandatory for the token exchange if using the Authorization Code endpoint, but optional if using the correct Client-Side token endpoint.
  • URI Mismatch: Even when supplying a redirect_uri, a discrepancy between https://app.ngrok.io/ (Dashboard) and https://app.ngrok.io (API Request) triggers the validation failure.

Why This Happens in Real Systems

This specific error is a common friction point in OAuth 2.0 implementations due to the tension between security and developer experience.

  • Strict Redirect Validation: To prevent Authorization Code Interception Attacks, the authorization server (Meta) verifies that the token request comes from the same client origin that initiated the login. If the browser redirects to https://domain.com/callback but the backend calls https://graph.facebook.com/...?redirect_uri=https://domain.com, the mismatch flags a potential security breach.
  • SDK Abstraction Leaks: High-level SDKs like facebook-javascript-sdk abstract the redirect process. Developers often assume FB.login() just “returns” a code. It actually performs a full navigation cycle. If the “Valid OAuth Redirect URI” in the dashboard is misconfigured, the SDK fails silently or passes a code bound to a bad URI.
  • Protocol Enforcement: Meta enforces HTTPS for production. ngrok provides HTTPS, but if the developer manually constructs a URL using http:// or forgets the domain mismatch, the handshake fails.

Real-World Impact

  • Integration Blockers: This error completely halts the WhatsApp Embedded Signup flow, preventing new users from connecting their WhatsApp accounts to the application.
  • Debugging Fatigue: The error message (“Please make sure your redirect_uri is identical…”) is often interpreted as a request to add a parameter to the code exchange request, leading to wild goose chases (e.g., adding &redirect_uri=... to the token URL) which does not work for the JS SDK flow.
  • Security Risk: Workarounds often involve disabling strict checks or weakening validation, which exposes the application to token theft if deployed in production.

Example or Code

The following code fixes the implementation by using the Client-Side Token Exchange flow, which removes the need for the redirect_uri parameter in the backend call, provided the frontend configuration is correct.

Frontend (Corrected JS)

window.fbAsyncInit = function() {
  FB.init({
    appId: '{APP_ID}',
    cookie: true,
    xfbml: true,
    version: 'v22.0'
  });
};

const fbLoginCallback = (response) => {
  if (response.authResponse) {
    // In Client-Side Flow, the SDK usually handles the token.
    // However, for WhatsApp signup, we often need the User Access Token.
    const accessToken = response.authResponse.accessToken;
    console.log('Got Access Token:', accessToken);

    // Send this ACCESS_TOKEN to your backend, NOT the code
    // if using the /me/accounts endpoint or Graph API directly.
    // If you strictly need an authorization code for backend exchange:
    // Ensure your app settings match exactly.
  } else {
    console.log('User cancelled login.', response);
  }
};

const launchWhatsAppSignup = () => {
  // Ensure 'response_type' is handled correctly.
  // If requesting a Code, the SDK handles the redirect.
  // If requesting Token, it returns it immediately.
  FB.login(fbLoginCallback, {
    config_id: '{CONFIG_ID}',
    response_type: 'token', // Switch to 'token' for simpler client-side usage
    // response_type: 'code', // Use this ONLY if you strictly follow Code Flow rules
    extras: {
      setup: {}
    }
  });
};

Backend (Corrected Python)

@app.get("/oauth_callback")
async def oauth_callback(code: str):
    if not http_client:
        return "Server Error: HTTP Client not ready"

    APP_ID = "ID"
    APP_SECRET = "SECRET"

    # NOTE: When using JS SDK 'response_type: token' or 'fb.login()',
    # the code is usually handled by the frontend.
    # If using 'response_type: code', you MUST include redirect_uri here.

    token_url = (
        f"https://graph.facebook.com/v22.0/oauth/access_token?"
        f"client_id={APP_ID}&"
        f"client_secret={APP_SECRET}&"
        f"code={code}&"
        f"redirect_uri=https://your-ngrok-url.com/" # MUST match Dashboard exactly
    )

    # In reality, for the specific error mentioned, 
    # it is often better to switch to 'response_type: token' 
    # and skip this token exchange entirely.

How Senior Engineers Fix It

Senior engineers solve this by eliminating ambiguity in the redirect chain.

  1. Harmonize Configuration: They ensure the “Valid OAuth Redirect URIs” in the Meta App Dashboard match the actual domain being used (e.g., https://abc123.ngrok.io/), paying attention to the trailing slash.
  2. Standardize the Flow: They switch to a single flow. For Embedded Signup, the recommended approach is usually the Client-Side Flow (using response_type: 'token').
    • Why? It avoids the redirect_uri mismatch error entirely because the SDK returns an Access Token directly, skipping the code-to-token exchange step where the error occurs.
  3. URL Normalization: They write helper functions to normalize URLs before comparison to ensure http:// vs https:// or domain.com vs domain.com/ don’t break logic.
  4. Verify the “Code”: If a code is used, they validate that it hasn’t expired (codes are short-lived) and that the session state matches.

Why Juniors Miss It

Juniors struggle with this because they treat the Authorization Code and Access Token as interchangeable data payloads, missing the binding mechanism.

  • Abstracted Flow: They don’t visualize the browser redirects happening behind FB.login(). They see “Input: Click Button, Output: Code,” not “Input: Click Button -> Redirect -> Validation -> Code.”
  • Documentation Fragmentation: Meta’s documentation splits between “Login” and “Graph API,” making it hard to see that the redirect_uri is a shared secret between the two.
  • Parameter Confusion: They read “redirect_uri is required” and try to pass it to FB.login() or the /access_token endpoint blindly, without realizing the SDK might be generating a random URI or using a default that isn’t configured in the App Dashboard.