Why is Redirect URL Fully Qualified in Azure AD B2C?

Why does the redirect URL have to match completely? Wouldn't matching at the domain level be sufficient enough for proper security?

What if I had hundreds of paths?

example urls:

1. https://myawesomesite.com
2. https://myawesomesite.com/account/profile
3. https://myawesomesite.com/games/fungame/points
4. https://www.myawesomesite.com/games/fungame/points

...

I would have to enter the 4 above redirect urls into my B2C app configuration.

Solution 1:

It is common (and easiest) for all authentication requests to contain two redirect URLs:

1. One (often known as the reply URL) that is passed in the "redirect_uri" parameter, which must be registered with Azure AD B2C, to which all authentication responses are returned from Azure AD B2C to the relying party application. An example of this is https://www.myawesomesite.com/oidc-signin.
2. Another (often known as the return URL) that is round-tripped in the "state" parameter, which doesn't have to be registered with Azure AD B2C, to which the end user is returned after the relying party application has handled the authentication response. An example of this is https://www.myawesomesite.com/games/fungame/points.

An authentication handler, such as the ASP.NET Core authentication middleware, manages these redirect URLs for you.

For instance, when the authentication handler creates the authentication request, it encodes the currently protected URL (e.g. https://www.myawesomesite.com/games/fungame/points) in the "state" request parameter.

To ensure this URL isn't tampered with, the "state" parameter should be protected, using encryption or signing.

When the authentication handler processes the authentication response, assuming it is a successful response, it creates an identity cookie and redirects the end user from https://www.myawesomesite.com/oidc-signin to the originally protected URL in the "state" response parameter.

Solution 2:

This is actually discussed in RFC 6819 "OAuth 2.0 Threat Model and Security Considerations" sections 4.1.5, 4.2.4 and 5.2.3.5.

4.1.5. Threat: Open Redirectors on Client

An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirect URI, an attacker can use an open redirector operated by the client to construct a redirect URI that will pass the authorization server validation but will send the authorization "code" or access token to an endpoint under the control of the attacker.

Impact: An attacker could gain access to authorization "codes" or access tokens.

Countermeasures:

o Require clients to register full redirect URI (Section 5.2.3.5)."

Section 5.2.3.5 talks about the cases where this may be too restrictive and purposes alternate solutions.

Often times, the state parameter can also be used to redirect deterministically as suggested by Chris. However, you have to ensure that such a solution also does not end up being an open redirector, so the state parameter will either need to be protected (e.g. encrypted/signed), or used in conjunction with cookies.