acquire_token_interactive() allows customizing the redirect URI's path

[rayluo]

Traditionally, most parts of the redirect URI for a desktop app is hardcoded in this library as http://localhost, and only the port is customizable (by a port optional parameter).

Sometimes, an app targets to multiple "platforms" (in this context, "platform" means web, native/desktop, spa, etc.), and they may all run on localhost during development. Those multiple redirect URIs differentiate with each other only by path, as described in the second last bullet point of this "localhost exceptions" documentation.

In this PR, the path will become customizable, but the remaining content (schema and host) remains constant. Therefore, the new optional parameter is path, rather than redirect_uri.

This will resolve #574 .

[rayluo]

Agreed with your suggestion 2 & 3. Will wait for the input from those pinged folks.

With regard to suggestion 1, the http://localhost:port/path is a valid redirect uri for a desktop app using system browser, per the specs. So, it is a matter of whether/how it will be implemented.

The HTTP listener built in MSAL can't tell between http://localhost:port/path1 and http://localhost:port/path2. I am concerned about potential vulnerability this can introduce.

That is an implementation detail that can be discussed offline. Traditionally, MSAL uses ephemeral port, state validation and PKCE for security. Path is merely a short well-known string which does not provide any security cryptographically anyway.

[bgavrilMS]

Agreed with your suggestion 2 & 3. Will wait for the input from those pinged folks.

With regard to suggestion 1, the http://localhost:port/path is a valid redirect uri for a desktop app using system browser, per the specs. So, it is a matter of whether/how it will be implemented.

The HTTP listener built in MSAL can't tell between http://localhost:port/path1 and http://localhost:port/path2. I am concerned about potential vulnerability this can introduce.

That is an implementation detail that can be discussed offline. Traditionally, MSAL uses ephemeral port, state validation and PKCE for security.

That's an excellent document you found. So I guess the user scenario is to use 1 app registration for both web and desktop? Smth like:

[rayluo]

That's an excellent document you found. So I guess the user scenario is to use 1 app registration for both web and desktop? Smth like: ...

That is correct. That is the scenario that app developers run into, every time they need to start their app locally for development or debug purpose.

[localden]

Minor feedback on documentation, @rayluo - other than that, looking good.