Skip to content

README.md

Latest commit

 

History

History
191 lines (124 loc) · 11.3 KB

README.md

File metadata and controls

191 lines (124 loc) · 11.3 KB

Google Auth Proxy

Fix for Error 400: invalid_request — Parameter not allowed for this message type: username
when using Google sign-in with Microsoft Entra External ID (formerly Azure AD B2C).

Created by John Matthew Young

Also Searched As

  • 400 error Google sign in Microsoft External ID username not allowed
  • Entra External ID Google OAuth username parameter rejected
  • invalid_request username parameter not allowed Google federated identity
  • Azure AD B2C Google IDP 400 error username
  • flowName=GeneralOAuthFlow 400 error Google sign in
  • Request details flowName=GeneralOAuthFlow username not allowed

Related Microsoft Q&A Reports

This is a known, unresolved bug with multiple independent reports on Microsoft Q&A. If you found this repo from one of these threads, this proxy is the fix:

None of these threads have a first-party fix from Microsoft. This proxy is the working workaround.

The Problem

When you configure Google as a federated identity provider in Microsoft Entra External ID and a user tries to sign in through a SignInSignUp user flow, the login fails with:

Access blocked: Authorization Error Error 400: invalid_request Parameter not allowed for this message type: username

The error screen shows request details including flowName=GeneralOAuthFlow, which confirms this is Entra's general OAuth flow — not a misconfiguration on your end.

This happens because Entra automatically appends a username parameter to the OAuth2 authorization request it sends to Google. Google's OAuth2 implementation does not accept this parameter and rejects the request outright.

Direct "Sign in with Google" flows work fine — the issue is specific to Entra-orchestrated flows.

Error 400 Request: flowName=GeneralOAuthFlow Parameter not allowed for this message type: username Source: Microsoft Q&A — Encountering 400 invalid_request error during the Entra SignInSignUp user flow

The Fix

Both solutions below work by placing a lightweight proxy between Entra and Google. The proxy intercepts the authorization request, strips the username parameter, and forwards it cleanly to Google.

The key change in both cases is pointing Entra's Well-known endpoint at the proxy instead of Google directly. Normally you would set this to Google's own discovery URL (https://accounts.google.com/.well-known/openid-configuration) — the proxy replaces that entry point while everything else stays the same.

Hosted Instance

A hosted instance of this proxy is available at https://google-auth-proxy.jmatthewyoung.com. It runs directly off this source code and does not log, store, or inspect any data from proxied requests — it only strips the username parameter and redirects.

That said, for production applications it is always best practice to host this yourself so you are not depending on a third-party service for your authentication flow. Instructions for that are in Option 2 below.

Note

Message to Microsoft: This bug does not appear when you click Sign In With Google and log in fresh — that works perfectly. The bug appears when you return to the site and see your email listed as a selectable account. You click it, get the "Taking you to your organization's sign-in page" screen, and then hit the error below. If you go back, choose "Use another account → Sign in with Google", and sign in with the exact same account, it works fine. The reason is that Entra is sending a parameter called username and Google rejects it. I don't know why you send it, I don't particularly care — but the bug is brutal and makes the built-in Google identity provider nearly useless. Please fix this and make this proxy irrelevant.

Option 1 — Easy: Use the Hosted Proxy (Development/Less Secure Applications)

A hosted instance of this proxy is already running. You just need to update your Entra Google identity provider configuration to point to it.

Steps

  1. In the Azure Portal, go to Entra External ID → External Identities → All identity providers.
  2. Select the Custom tab — do not use the built-in Google identity provider listed on the default tab. The built-in one does not allow you to override the well-known endpoint, which is what this proxy requires.
  3. Click Add new → OpenID Connect.

Add new OpenID Connect provider in Entra Source: Microsoft Learn — Custom OIDC federation for Entra External ID

  1. Fill in the settings as follows. Setting the Display name to Google means the button on your sign-in page will read "Sign in with Google".
Field Value
Display name Google
Well-known endpoint https://google-auth-proxy.jmatthewyoung.com/api/well-known/openid-configuration
Issuer URI https://accounts.google.com
Client ID (your Client ID from Google Cloud Console)
Client Authentication Method Client secret
Client Secret (your Client Secret from Google Cloud Console)
Scope openid profile email
Response Type code

The only field that differs from a standard Google OIDC setup is the Well-known endpoint — instead of pointing directly at https://accounts.google.com/.well-known/openid-configuration, you point it at the proxy. Everything else is identical to what Google requires.

  1. Save the configuration and test your sign-in flow.

No code changes, no infrastructure to manage.

Option 2 — Self-Hosted: Deploy Your Own Proxy (Production/Best Practice)

Use this repository to deploy your own instance of the proxy to Azure Functions. This gives you full control over the infrastructure.

Prerequisites

Run Locally

git clone https://github.com/your-username/google-auth-proxy.git
cd google-auth-proxy
dotnet run --project GoogleAuthProxy/GoogleAuthProxy.csproj

The proxy will start on http://localhost:7136. You can verify it is working by visiting:

http://localhost:7136/api/well-known/openid-configuration

You should see Google's OIDC discovery document with the authorization_endpoint rewritten to point to the local proxy.

Deploy to Azure

  1. Create a Function App in Azure (Runtime: .NET 8, OS: Windows or Linux).
  2. Deploy using the Azure Functions Core Tools: 
    func azure functionapp publish <YOUR_FUNCTION_APP_NAME>
    Or publish directly from Visual Studio via Right-click project → Publish.
  3. Note your deployed URL — but read the next section before using it.

Important: You Must Use a Custom Domain

Do not use the default *.azurewebsites.net URL with Entra. When Google redirects the user back through the proxy after authentication, Chrome will display a "Dangerous site" warning for azurewebsites.net domains. Users will see a scary security interstitial before completing login.

Set up a custom domain on your Function App (e.g. auth-proxy.yourdomain.com) and use that as your proxy URL. Azure's documentation covers this under App Service custom domains.

Configure Entra to Use Your Proxy

Follow the same settings as Option 1, substituting your custom domain:

Field Value
Display name Google
Well-known endpoint https://auth-proxy.yourdomain.com/api/well-known/openid-configuration
Issuer URI https://accounts.google.com
Client ID (your Client ID from Google Cloud Console)
Client Authentication Method Client secret
Client Secret (your Client Secret from Google Cloud Console)
Scope openid profile email
Response Type code

How It Works

The proxy exposes two endpoints that mirror Google's OIDC interface:

Endpoint What it does
GET /api/well-known/openid-configuration Returns Google's OIDC discovery doc with authorization_endpoint rewritten to point to the proxy
GET /api/auth Receives the auth request from Entra, strips the username parameter, and redirects to Google

Entra reads the discovery doc, sees the proxy's /api/auth as the authorization endpoint, sends the request there, and the proxy silently removes username before forwarding to Google.

Differences vs. the Built-in Google Identity Provider

Pro: Users can select a previously signed-in account from the account picker screen. If that account was originally signed in with Google, it will work correctly — no error, no workaround needed.

Con: On the sign-in screen, the Google button will display a generic blue circle icon instead of the Google logo. This is a cosmetic side effect of using a custom OIDC provider rather than the built-in one, and may signal to observant users that something non-standard is in play.

Con: Because this custom OIDC provider is treated as a completely separate identity provider from the built-in Google one, any existing users who previously signed in via the built-in Google IDP will not automatically carry over. Before they can sign in through the proxy-backed provider, their account will need to be deleted or have its redemption status reset in Entra so they can re-authenticate and be associated with the new provider. This is a one-time migration cost per affected user, but worth planning for if you have existing users.