AzureAD / microsoft-authentication-library-for-java

Microsoft Authentication Library (MSAL) for Java http://aka.ms/aadv2
MIT License
288 stars 144 forks source link

[Bug] http://127.0.0.1 does not work as redirect URI for AcquireTokenInteractive #824

Open fethullahmisir opened 5 months ago

fethullahmisir commented 5 months ago

Library version used

1.15.0

Java version

8

Scenario

PublicClient (AcquireTokenInteractive, AcquireTokenByUsernamePassword)

Is this a new or an existing app?

This is a new app or experiment

Issue description and reproduction steps

Using http://127.0.0.1 as the redirect URI does not work because it is overridden with http://localhost. This override causes the login to fail as http://localhost is not defined in the App Registration. According to Microsoft documentation, 127.0.0.1 should be preferred over localhost.

Workaround: Using an address with a fixed port like http://127.0.0.1:3490 works because the redirect URI is not overridden. However, this workaround is not ideal as it introduces the risk of port conflicts.

Relevant Documentation: According to Microsoft Documentation, 127.0.0.1 should be preferred over localhost.

Relevant code snippets

// Does not work, because redirect url is updated to http://localhost
    InteractiveRequestParameters parameters = InteractiveRequestParameters
                .builder(new URI("http://127.0.0.1"))
                .scopes(scope)
                .build();

// Works - redirect url remains http://127.0.0.1:3490
     InteractiveRequestParameters parameters = InteractiveRequestParameters
                .builder(new URI("http://127.0.0.1:3490"))
                .scopes(scope)
                .build();

Expected behavior

The redirect URI should remain as http://127.0.0.1 .

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

The relevant place in code is:

https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/msal4j-sdk/src/main/java/com/microsoft/aad/msal4j/AcquireTokenByInteractiveFlowSupplier.java#L103

The URI is hard coded and should be loaded from the interactiveRequestParameters() instead.

 private void updateRedirectUrl() {
        try {
            URI updatedRedirectUrl = new URI("http://localhost:" + httpListener.port());
            interactiveRequest.interactiveRequestParameters().redirectUri(updatedRedirectUrl);
            LOG.debug("Redirect URI updated to" + updatedRedirectUrl);
        } catch (URISyntaxException ex) {
            throw new MsalClientException("Error updating redirect URI. Not a valid URI format",
                    AuthenticationErrorCode.INVALID_REDIRECT_URI);
        }
    }
bgavrilMS commented 5 months ago

We recommend using the broker for logging in with AAD.

https://learn.microsoft.com/en-us/entra/msal/java/advanced/using-wam-and-the-msal4jbrokers-package

rayluo commented 5 months ago

Relevant Documentation: According to Microsoft Documentation, 127.0.0.1 should be preferred over localhost.

Interesting. At one point, that recommended 127.0.0.1 was unable to be set via Azure Portal; such a limitation was also - and is still - mentioned in that doc: unable to use 127.0.0.1 For that historical reason, localhost is widely used in many apps and even hardcoded in some MSAL implementations.

It seems that the portal accepts 127.0.0.1 now. Therefore, this bug report is fair.

P.S.: Perhaps localhost is still the only way to support IPv6, for now.

fethullahmisir commented 5 months ago

The Documentation uses the Screenshot from Single Page Application Section of the Portal.

In the "Mobile and desktop applications" section, its possible to add http://127.0.0.1 without needing to use the Manifest workaround.

CleanShot 2024-06-05 at 10 38 26@2x
rayluo commented 5 months ago

In the "Mobile and desktop applications" section, its possible to add http://127.0.0.1 without needing to use the Manifest workaround.

It is possible now. It wasn't possible before. I don't know when it changed, but I am sure it wasn't possible even for "mobile and desktop app". Just a FYI.