[Bug] AcquireTokenInteractive browser does not propagate path & host properly

[shlomiassaf]

Library version used

4.56.0

.NET version

6

Scenario

PublicClient - desktop app

Is this a new or an existing app?

The app is in production, I haven't upgraded MSAL, but started seeing this issue

Issue description and reproduction steps

When using a public client, with AcquireTokenInteractive, the process does not respect the RedirectUrl provided and alters it in 2 sections

• The path
• The host

Path issue

For the path, it seems that any URI path component provided as a redirect URI is not honored, the client will send the redirect URI without the path

For example, http://localhost/webapp will yield the following login URL

https://login.microsoftonline.com/<TENANT>/oauth2/v2.0/authorize?scope=openid+profile+User.Read+offline_access&response_type=code&client_id=<CLIENT>c&redirect_uri=http%3A%2F%2Flocalhost%3A55982&client-request-id=<XYZ>&x-client-SKU=MSAL.NetCore&x-client-Ver=4.56.0.0&x-client-OS=Darwin+21.4.0+Darwin+Kernel+Version+21.4.0%3A+Fri+Mar+18+00%3A46%3A32+PDT+2022%3B+root%3Axnu-8020.101.4~15%2FRELEASE_ARM64_T6000&prompt=select_account&code_challenge=<CODE_CHG>&code_challenge_method=S256&state=b20c3315-aa4c-4f9c-a511-93d1ca3c7ce86970fc77-a4a6-4a56-a127-c97d8c0a9d46&client_info=1

I believe it originated here:

https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/6e129f6afdd4d46e35b430b637d8828e82ab4e45/src/client/Microsoft.Identity.Client/Platforms/Features/DefaultOSBrowser/DefaultOsBrowserWebUi.cs#L110-L122

The last row, just ignores the path component.

Host issue

for host, it seems that it forces http://localhost (which is for security, understood) but it does not allow 127.0.0.1

Here, the RedirectUrl is passed properly to the OIDC endpoint which then returns properly to the local browser, however a NOT FOUND error is displayed.

If I change it to "localhost" manually it will hit the server, i.e. the server is actually listening to another interface (localhost) while it sent 127.0.0.1 to OIDC.

Clearly, once hitting the server validation fails on URL mismatch...

https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/6e129f6afdd4d46e35b430b637d8828e82ab4e45/src/client/Microsoft.Identity.Client/Platforms/Features/DefaultOSBrowser/HttpListenerInterceptor.cs#L50

---

Both issues are relevant as per MS reply url documentation:

https://learn.microsoft.com/en-us/entra/identity-platform/reply-url

For path, it is the recommended approach when using multiple authentication flows as the host+port does not provide uniqueness (port is ignored)

For host, well, i've tried it since "path" did not work but with that as well, MS recommends "127.0.0.1" over "lcoalhost"

Relevant code snippets

No response

Expected behavior

No response

Identity provider

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

Regression

No response

Solution and workarounds

No response

[localden]

@shlomiassaf can you also please post the code that you are using to acquire a token with the public client application? Want to make sure that we're trying to reproduce the behavior exactly as you've tried it.

[iulico-1]

Is this issue still reproducing ? Can you provide sample code ?

[rayluo]

@iulico-1 , I did not try it personally, but I believe it shall be easy to attempt with the method provided by the reporter.

Path issue

For the path, it seems that any URI path component provided as a redirect URI is not honored, the client will send the redirect URI without the path

For example, http://localhost/webapp will yield the following login URL

https://login.microsoftonline.com//oauth2/v2.0/authorize?scope=openid+profile+User.Read+offline_access&response_type=code&client_id=[CLIENT]&redirect_uri=http%3A%2F%2Flocalhost%3A55982&client-request-id=&x-client-SKU=MSAL.NetCore&x-client-Ver=4.56.0.0&x-client-OS=Darwin+21.4.0+Darwin+Kernel+Version+21.4.0%3A+Fri+Mar+18+00%3A46%3A32+PDT+2022%3B+root%3Axnu-8020.101.4~15%2FRELEASE_ARM64_T6000&prompt=select_account&code_challenge=&code_challenge_method=S256&state=b20c3315-aa4c-4f9c-a511-93d1ca3c7ce86970fc77-a4a6-4a56-a127-c97d8c0a9d46&client_info=1

I believe it originated here.

For what it's worth, the same "path" feature gap also exists in MSAL Python, which I proposed a PR for it last year. If/when you are investigating the current issue here, you may want to also cross-reference the discussion in that MSAL Python PR to better understand the topic.