I stumbled upon this issue while working on setting up DR for an internally written web app running in Azure. The solution is comprised of an app service plan, a web app, and backed by Azure SQL Database. It was really exciting to finally get a chance to be involved with a project like this and see firsthand how it all works when you need to failover from one region to another as smoothly as possible.

The web app is used by the company for tracking time spent on various projects. The user needs to be in a security group in order to access the site, and if they’re not authorized they are simply bounced to the company’s local intranet page. Interestingly enough, the account I was using for testing was in the right group, however, I would be end up being re-directed for some reason which wasn’t immediately obvious. That’s when tools like Fiddler are invaluable. I opened up Fiddler to run a trace and noticed something interesting right off the bat.

Note the error code begins with AADSTS, meaning you’re hitting the Azure AD service.  The app’s authentication provider is not able to return a token that is required for the OAuth2 implicit flow.  This flow is a simplified authentication flow, where a successful authentication request will directly result in an access token to be returned to the app.

You can resolve this using the following steps.

• Search and select the appropriate app registration in Azure AD.

• Under Manage, select Authentication, and check the ID tokens option under the Implicit grant section.

Under the covers, this sets the app’s oauth2AllowIdTokenImplicitFlow attribute to “true” in the manifest.

Enabling the ID tokens option allows OpenID Connect user sign-ins from App Service. I ran another trace after making the change and saw the traffic flow that I was expecting.

See this article for more information if you’re curious.