You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
@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.
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 URLI believe it originated here:
microsoft-authentication-library-for-dotnet/src/client/Microsoft.Identity.Client/Platforms/Features/DefaultOSBrowser/DefaultOsBrowserWebUi.cs
Lines 110 to 122 in 6e129f6
The last row, just ignores the path component.
Host
issuefor
host
, it seems that it forceshttp://localhost
(which is for security, understood) but it does not allow127.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...
microsoft-authentication-library-for-dotnet/src/client/Microsoft.Identity.Client/Platforms/Features/DefaultOSBrowser/HttpListenerInterceptor.cs
Line 50 in 6e129f6
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
The text was updated successfully, but these errors were encountered: