CODEWITHSUNDEEP
c#asp.net-coreopenid-connectazure-ad-b2c
Chris
Chris

Reputation: 46

Azure Ad - Redirect Uri hidden behind authorization

I'm encountering an issue where I can observe an infinite redirect loop. My project is based on the official MS example - active-directory-b2c-dotnet-webapp-and-webapi

Does "Redirect URI" (defined in Azure Portal) have to be publicly accessible endpoint?

What would happen if in my controller I decorated it with an [Authorize] attribute?

So basically in this example Redirect Uri (set as website root, i.e. localhost:1234/) would also be a route for an action in the controller, which requires authorization.

[Authorize]
public class ControllerA : Controller
{
    [Route("~/")]
    public ActionResult Index()
    {
    }
}

Could it cause an infinite redirect loop?

Removing the route attribute fixes the problem, but at the same time, I feel like it's not a real cause of the issue.

I imagine that OWIN authorization is higher in the application stack compared to the controller's authorization, so I think that OWIN authorization middle-ware would parse the response from Azure Ad in a first place, instead of enforcing [Authorize] attribute policy and rejecting it upfront.

Upvotes: 0

Views: 554

Answers (2)

Chris
Chris

Reputation: 46

The core of the problem and solutions are described in following document - System.Web response cookie integration issues. I've implemented 3rd solution (reconfigure the CookieAuthenticationMiddleware to write directly to System.Web's cookie collection) and it has resolved the issue. What lead me to discover that the cookies were the issue is another StackOverflow's question, which describes a really similar symptoms to the one I was observing.

A fact that the default route [Route("~/")] was mapped to one of the controller's methods which required authorization, and that it was also matching a redirect_uri that I've set up in Azure Portal was not a culprit. In my opinion this is a proof that redirect_uri call will be handled directly by OWIN auth middleware and it won't even reach a controller's method.

Upvotes: 0

Marc LaFleur
Marc LaFleur

Reputation: 33124

You can certainly create an infinite loop scenario this way but it will end up short-circuited by Azure AD. After a few loops, it will stop redirecting back and surface an error.

The redirect_uri needn't be a publicly accessible URI, it will work with http://localhost for example. It need only be accessible by the client. After all, a "redirect" is simply an HTTP response issued by the server. It is actually executed by the client.

In general, the controller you're using for authorization (i.e. receiving the redirect) shouldn't be decorated by an [Authorize] at the class level. Typically you would only decorate the handful of methods that require a signed in user. That said, you could certainly decorate the class with [Authorize] so long as you decorate your callback endpoint with [AllowAnonymous].

Upvotes: 1

Related Questions