microsoft-authentication-library-for-dotnet icon indicating copy to clipboard operation
microsoft-authentication-library-for-dotnet copied to clipboard

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

Open shlomiassaf opened this issue 1 year ago • 5 comments

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.

image

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.

image

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

shlomiassaf avatar Mar 28 '24 18:03 shlomiassaf

@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.

localden avatar May 19 '24 02:05 localden

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

iulico-1 avatar Jul 03 '24 16:07 iulico-1

@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/<TENANT>/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=<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.

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.

rayluo avatar Jul 04 '24 04:07 rayluo

I'm experiencing the same issue with B2C.

anpin avatar Jul 14 '24 02:07 anpin

MSAL always expects http://localhost https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/4419b3ff4983fc7e99eff3dcb849cab39e7b7e48/src/client/Microsoft.Identity.Client/Platforms/Features/DefaultOSBrowser/HttpListenerInterceptor.cs#L50

But B2C always redirects to http://127.0.0.1:<PORT>/?<RESPONSE> even if redirect URI was set to http://localhost:<PORT>

anpin avatar Jul 14 '24 12:07 anpin