Which Version of MSAL are you using ?
Microsoft.Identity.Client 4.22.0, the latest from nuget.org.
Platform
netcore 3.1 on Windows 10.
What authentication flow has the issue?
Other? - please describe;
Is this a new or existing app?
This is a new app or experiment
Repro
PublicClient = PublicClientApplicationBuilder.Create(clientId)
.WithAuthority(AadAuthorityAudience.AzureAdMultipleOrgs)
.WithRedirectUri("http://localhost/myCustomPath")
.Build();
result = await PublicClient.AcquireTokenInteractive(scopes)
.ExecuteAsync();
Expected behavior
MSAL.NET should pick a random port (e.g. 1234), start listening on that port, and then make a login request with redirect_uri=http://localhost:1234/myCustomPath
Actual behavior
MSAL.NET picks a random port (e.g. 1234), starts listening on that port, and then make a login request with redirect_uri=http://localhost:1234
Possible Solution
Please honor my redirect URI.
Additional context/ Logs / Screenshots
The use of the root localhost path is problematic in Azure AD. Azure AD supports and encourages multi-platform multi-paradigm apps - in particular, if a developer wanted to expose the same product and functionality on a website and in a native client, such a developer is supported using the same client ID for each scenario. In fact, using the same client ID here is highly desirable, as this is the only way for the native and web client to share consent. Additionally, Azure AD determines the type of the redirect URI (web vs native) by taking the redirect URI from the request and finding the matching redirect URI on the app registration. That means that an application cannot use the same redirect URI for two different types of applications (web and native). By requiring MSAL.NET to use the root path, you block local development of websites that also use the root path for login (that usually happens on localhost).
Please enable me to use localhost with a path for my native applications. On the server side, this already works.
Additionally, this feature is a security recommendation in RFC8252 OAuth 2.0 for Native Apps (https://tools.ietf.org/html/rfc8252#section-8.10). The RFC says (emphasis added):
8.10. Authorization Server Mix-Up Mitigation
To protect against a compromised or malicious authorization server
attacking another authorization server used by the same app, it is
REQUIRED that a unique redirect URI is used for each authorization
server used by the app (for example, by varying the path component),
and that authorization responses are rejected if the redirect URI
they were received on doesn't match the redirect URI in an outgoing
authorization request.
The native app MUST store the redirect URI used in the authorization
request with the authorization session data (i.e., along with "state"
and other related data) and MUST verify that the URI on which the
authorization response was received exactly matches it.
So, this limitation in MSAL.NET makes it more difficult for clients to conform with this security recommendation.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4