IdentityTypeMismatch (Code 126) when calling Reporting API — email registered with Google sign-in

IdentityTypeMismatch (code 126) occurs when the identity used to obtain the OAuth token does not match the identity type that actually has Microsoft Advertising access (for example, Microsoft account vs. Google account for the same email).

Microsoft Advertising now supports authenticating users with either Microsoft OAuth (Azure identity) or Google OAuth 2.0. For users who sign in to Microsoft Advertising with Google, the API must also authenticate them via Google OAuth, not via the Microsoft identity platform.

Answers to the specific questions:

1. Obtaining an OAuth refresh token for a Google-sign-in user Use the Google OAuth 2.0 flow and then use the resulting Google access token/refresh token with Microsoft Advertising:
   • Microsoft Advertising supports Google OAuth 2.0 as an authentication provider alongside Microsoft OAuth.
   • After receiving the Google authorization code, the application must exchange it at Google’s token endpoint for an access token and refresh token.
   • The Google access token is then used in Microsoft Advertising API calls; the request headers and developer token usage remain unchanged.
   • When using the SDKs, use the Google-specific OAuth classes instead of the standard Microsoft OAuth classes:
     • GoogleOAuthDesktopMobileAuthCodeGrant
     • GoogleOAuthWebAuthCodeGrant
   • These classes require a Google client ID, client secret, and redirect URI from the Google Cloud project, and they manage the Google authorization code grant and token refresh.
   • Important behavior: when refreshing an access token with a Google refresh token, Google does not return a new refresh token; the original refresh token remains valid until it expires or is revoked.
   In short, for a user whose Microsoft Advertising identity is a Google account, obtain the refresh token via Google’s OAuth endpoints and use that token with Microsoft Advertising, rather than using login.microsoftonline.com.
2. Recommended pattern when all org emails use Google Workspace federated sign-in For organizations that use Google accounts to sign in to Microsoft Advertising:
   • Standardize on Google OAuth 2.0 for API authentication.
   • Register a Google OAuth client (web/desktop/mobile as appropriate) and configure the redirect URI.
   • Use the Google OAuth flow to obtain access and refresh tokens for each user who has Microsoft Advertising access.
   • Store the refresh tokens securely and use them to refresh access tokens as needed.
   • For SDK-based integrations, use GoogleOAuthWebAuthCodeGrant or GoogleOAuthDesktopMobileAuthCodeGrant to manage the Google-based sign-in and token lifecycle.
   • Once an access token is obtained (from Google or Microsoft), the API call pattern is identical: include the access token in the AuthenticationToken header along with the developer token and required IDs.
   This pattern avoids identity-type mismatches because the same Google identity that signs in to the Microsoft Advertising UI is also used to obtain tokens for API access.

References:

• Authentication With the SDKs
• Make your first API call
• Request user consent