Azure AD reply url: how to add several urls when using openid connect auth

Question

I'm trying to build a ASP.NET MVC app which doesn't allow access to anonymous user (with the exception of a custom URL that is to be shown to authenticated users which aren't allowed to use the app).

Now, I've register my app in the azure portal (portal.azure.com) and I'd like to use several URLs. I've added two entries:

1. https://localhost/test
2. https://www.test.com

I'm using the following code to configure authentication at startup:

public void ConfigureAuth(IAppBuilder app) {
    app.SetDefaultSignInAsAuthenticationType(
          CookieAuthenticationDefaults.AuthenticationType);
    app.UseCookieAuthentication(new CookieAuthenticationOptions());
    app.UseOpenIdConnectAuthentication(
      new OpenIdConnectAuthenticationOptions {                                                                                        
          ClientId = clientId,                                                                                        
          Authority = authority,                                                                                        
          PostLogoutRedirectUri = postLogoutRedirectUri,                                                                                        
          Notifications = new OpenIdConnectAuthenticationNotifications {
            SecurityTokenValidated = VerificaUtilizadorAutenticado,
            AuthenticationFailed = TrataErroAutenticacao
         }
     });
}

Everything seemed to be working fine, but after publishing the app, it seems like I can only use one of the URIs. I've searched and it seems like I can use the RedirectUri property of the OpenIdConnectAuthenticationOptions to set up the reply url. So, I've tried adding this to the setup:

RedirectUri = "https://localhost/test",

Unfortunately, doing that breaks everything and the browser gets stuck between my app and MS' login page. Since the user is logged in, it redirects the user back to my app. However, it seems like setting the RedirectUri prop does not generate the app's authentication cookie, so it sends the user back to the login page.

If I remove the RedirectUri, then I get redirected to the https://www.test.com site, even though I'm trying to access the https://localhost/test web app.

I'm not sure what, but I'm missing something...Can anyone help?

Thanks.

Luis

Answer 1

When you send a user who wants to sign in to the AAD Login Endpoint (https://login.microsoftonline.com), you will need to specify where you want the user (and the Authorization Code) to be redirected back to.

You specify this in two ways:

1. You must configure a Reply URL in your app's main configuration as a part of app creation.

2. You must specify a Reply URL in your Login URL, which exactly matches one of the URLs you configured:

   From the Authorization Code Grant Flow documentation:

   https://login.microsoftonline.com/{tenant}/oauth2/authorize?
   client_id=6731de76-14a6-49ae-97bc-6eba6914391e
   &response_type=code
   &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F   <-- this guy
   &response_mode=query
   &resource=https%3A%2F%2Fservice.contoso.com%2F
   &state=12345
   

If you do not specify a Redirect URI in your Login URL, the user will be redirected to the first URL specified in your app's registration. That doesn't sound so bad, but know that AAD treats your Reply URLs as an unordered list, so depending on the server you hit, or how data got replicated, you might observe different redirection behaviors across different sign-in attempts. That is why it is important to ALWAYS specify the redirect_uri parameter in your login endpoint.

I feel like many of your problems may be solved if you use the ADAL libraries to authenticate rather than the libraries shown in your sample code, but if you do not want to use these, then you will need to share more details like the HTTP trace of the authentication process.

Answer 2

Ok, after some digging, I've noticed that the problem I was having when setting the redirecturi was that I was missing...a slash (/). So, adding the / to the URL defined on the portal and putting it also in the redirecturi of the options object was enough to make it work against different URI...