ID tokens can't be used for the OBO flow

Date: May 1, 2018 Endpoints impacted: Both v1.0 and v2.0 Protocols impacted: Implicit flow and on-behalf-of flow After May 1, 2018, id_tokens can't be used as the assertion in an OBO flow for new applications. Access tokens should be used instead to secure APIs, even between a client and middle tier of the same application. Apps registered before May 1, 2018 will continue to work and be able to exchange id_tokens for an access token; however, this pattern isn't considered a best practice. To work around this change, you can do the following: Create a web API for your application, with one or more scopes. This explicit entry point will allow finer grained control and security. In your app's manifest, in the Azure portal or the app registration portal, ensure that the app is allowed to issue access tokens via the implicit flow. This is controlled through the oauth2AllowImplicitFlow key. When your client application requests an id_token via response_type=id_token, also request an access token (response_type=token) for the web API created above. Thus, when using the v2.0 endpoint the scope parameter should look similar to api://GUID/SCOPE. On the v1.0 endpoint, the resource parameter should be the app URI of the web API. Pass this access token to the middle tier in place of the id_token.