AzureAD / microsoft-authentication-library-for-dotnet

Microsoft Authentication Library (MSAL) for .NET
https://aka.ms/msal-net
MIT License
1.41k stars 345 forks source link

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

Open shlomiassaf opened 8 months ago

shlomiassaf commented 8 months ago

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

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

localden commented 6 months ago

@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 commented 5 months ago

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

rayluo commented 5 months ago

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

anpin commented 4 months ago

I'm experiencing the same issue with B2C.

anpin commented 4 months ago

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>