Why localhost redirect URI for Azure AD desktop app / MSAL, and how does it work?

Question

I have seen it recommended to use http://localhost as the redirect URI for Azure AD app registrations for desktop apps. Can anyway explain why localhost is used, how this actually works (technical details), and what makes this secure?

For example, we have a 3rd party desktop app which integrates with Excel to pull data from our ERP via web services. It uses Azure AD app registration to authenticate as the current user using MSAL and retrieve data on their behalf, and it requires localhost to be setup as the redirect URI.

When the Azure AD token is sent back to the generic localhost redirect URI, how does it know to return back to the app that originated the request, vs. going to a locally hosted website, or any other locally installed app that is using MSAL or listening on port 80?

I understand that localhost is the recommended setting from various article I have read, but I'm just trying to understand why and how it works.

References

https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url

A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it's important you register the correct location as part of the app registration process

https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-app-registration#redirect-uris

As a security best practice, we recommend explicitly setting https://login.microsoftonline.com/common/oauth2/nativeclient or http://localhost as the redirect URI

Answer 1

When application is registered in Azure AD we need to provide the desired urls for the application. When authenticated user will be redirected to this particular url.

Here we need to add Urls that we are using .It takes according to code configuration of the application.

Localhost runs on local computer which is the secure way and mostly run during development or testing stage.

According to "ASPNETCORE_ENVIRONMENT" selected ,application is redirected to localhost or web app url based on that.

Launchsettings.json:

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "https://localhost:3110/",
      "sslPort": 44321
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "webApp": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Production"
      },
      "applicationUrl": "https://localhost:44321/"
    }
  }
}

It checks for the environment ,the set redirect for that environment and runs it.

When the user clicks the "Sign in" button in the application, the browser will send a request to Azure AD., the request will remain in your own system when http://localhost is used.

When the Azure AD token is sent back to the generic localhost redirect URI, it is sent as a query string parameter in the URL which contains the authorization code with which the application uses it to request an access token from Azure AD.

This is secure because it prevents other applications from intercepting the authorization code. Other applications cannot see the authorization code .

Answer 2

I finally found the answer after reading through MANY articles which led me to RFC 8252. Even though just http://localhost is specified in the Azure AD app redirect URI list, it really allows redirecting on any localhost port (per RFC 8252 Section 7.3) which states "The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request".

So then the Windows desktop app would:

1. obtain an available ephemeral port from the OS
2. open an exclusive network socket on that port, and listen for the response.
3. initiate the MSAL process supplying localhost:step1port# as the redirect URI, which opens the system browser, where the user supplies their AAD credentials
4. once the MSAL auth browser process is complete, then it send the auth token back to localhost:step1port#, which the desktop app is listening on so it can receive the response.
5. close the localhost socket opened in step 2

REFERENCES:

https://datatracker.ietf.org/doc/html/rfc8252#section-7.3

Native apps that are able to open a port on the loopback network
interface without needing special permissions (typically, those on
desktop operating systems) can use the loopback interface to receive
the OAuth redirect.

Loopback redirect URIs use the "http" scheme and are constructed with the loopback IP literal and whatever port the client is listening on. That is, "http://127.0.0.1:{port}/{path}" for IPv4, and "http://[::1]:{port}/{path}" for IPv6. An example redirect using the IPv4 loopback interface with a randomly assigned port:

 http://127.0.0.1:51004/oauth2redirect/example-provider

An example redirect using the IPv6 loopback interface with a randomly assigned port:

 http://[::1]:61023/oauth2redirect/example-provider

The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating
system at the time of the request.

Clients SHOULD NOT assume that the device supports a particular
version of the Internet Protocol. It is RECOMMENDED that clients
attempt to bind to the loopback interface using both IPv4 and IPv6
and use whichever is available.

https://datatracker.ietf.org/doc/html/rfc8252#appendix-B.3

Both traditional and Universal Windows Platform (UWP) apps can
perform authorization requests in the user's browser. Traditional
apps typically use a loopback redirect to receive the authorization
response, and listening on the loopback interface is allowed by
default firewall rules. When creating the loopback network socket,
apps SHOULD set the "SO_EXCLUSIVEADDRUSE" socket option to prevent
other apps binding to the same socket.