Notice for developers using Azure AD B2C tenants configured for Google sign-ins

Gepost op 14 maart, 2017

Senior Program Manager, Azure Active Directory

On April 20th 2017, Google will start blocking OAuth requests from embedded browsers, called "web-views". If you are using Google as an identity provider in Azure Active Directory B2C, you might need to make changes to your applications to avoid downtime. For more information about Google's plans, see Google's blog post.

Applications not impacted

We do not expect any impact for applications that:

  • Only use local accounts or do not have Google as an social identity provider
  • Web applications / Web APIs
  • Desktop (Windows) applications

Applications impacted

Applications impacted are those that have configured Google as an social identity provider in Azure AD B2C and support Android or iOS using:

  • Xamarin and MSAL Preview
    • Given it's preview status, MSAL should not be in use in production, but in case you did, contact Azure Support and we'll help you out.
  • Any library that uses embedded web-views such as AndroidAuthClient/OIDCAndroidLib (Android), NXOAuth2Client (iOS) and ADAL Experimental (iOS & Android) or codes against the protocol using embedded web-views directly, WebView (Android) and UIWebView (iOS). Android and iOS B2C samples posted before today used some of these libraries.
    • Our updated Android and iOS samples have instructions and working code with AppAuth, an open source library that uses the system web-views.

Azure AD B2C support for System Web-Views

Traditionally, applications using embedded web-views send an OAuth request to an identity provider with a redirect URN such as urn:ietf:wg:oauth:2.0:oob. Once the user signed in with the identity provider and the identity provider attempted to redirect the user back to the URN, the application, having full control of the web-view, would intercept the response and grab the authorization code.

Conversely, applications using system web-views do not have control over the web-view and thus can't intercept the OAuth response, they need a way for the system web-view when to return control back to the application. To support system web-views, Azure AD B2C has added support for custom redirect URIs for native clients (e.g. com.onmicrosoft.fabrikamb2c.exampleapp://oauthredirect) which developers can set up in their application configurations to ensure that the system web-view sends the response back to the application. Also, to ensure that only the application that generated the OAuth request can redeem the authentication code, Azure AD B2C added support for Proof Key for Code Exchange (PKCE).

If you run into any issues please contact Azure Support or if you have coding questions, don't hesitate to post on StackOverflow using the azure-ad-b2c tag.