Should I explicitly not use a standard URL with MSAL authentication?

Question

All of the MSAL documentation wants me to use a prefix such as msalGUID:/// when authenticating back to the local device.

Then there is the oddball url urn:ietf:wg:oauth:2.0:oob that appears by default in the MSAL portal.

Since every URL I list there is essentially a backdoor into my application, I want to understand the security benefit of each option.

• Why should I use the documented msalGUID:// scheme?
• Should I not use an iOS Universal Link / fully qualified URL?
• What is the benefit of the urn:ietf:wg:oauth:2.0:oob, and https://login.live.com/oauth20_desktop.srf?
• What should I be aware of w.r.t. interactions with Microsoft Authenticator, which likely depends on this?

Answer 1

Background

There's a few attack vectors & usability cases that come into play when considering the redirect URI your app will use.

First, is your app going to be signing in users from an authorization agent that is not sandboxed to your app. If you're using MSAL, then the answer is almost always yes (unless you have explicitly opted to use in-app WebViews).

Cases to consider

If so, then you have two cases to consider: accidental collisions of redirect URIs (usability issue) and malicious apps intentionally trying to intercept a user being redirected back to your app (security issue).

Case 1: Naive apps

To address the former, MSAL has chosen msal<ClientID>://auth as it's unique to each app registration. There's a high amount on randomness in this format (that is lost with urn:ietf:wg:oauth:2.0:oob) which prevents the scenario in which multiple apps on the device are listening on the same URI and "accidentally" get the response. For a user, this is extremely frustrating and would impact their experience with their app. To summarize the best practice to address this, use a highly random URI that avoids accidental collision with other apps.

Case 2: Malicious apps

To address the latter, MSAL implements the Proof Key for Code Exchange (PKCE) protocol to eliminate this attack vector. To expand on the scenario, it's similar to the above scenario, except for the app has captured the response intentionally and intends to exchange the authorization code on your behalf. With PKCE, only the app that initiated the request can exchange the auth code.

Summarizing answers

To quickly answer your bullets,

1. Covered above.
2. If you're familiar with universal links and how to setup the necessary steps, this may be a good option for verifying that your app registration is only used by you.
3. These are intended for apps using in-app WebViews where there's stronger security guarantees related to the fact it's not leaving the app.
4. MSAL does not currently integrate into the Authenticator to complete auth requests. When it does, apps will likely be required to complete an enhanced registration related to redirect URIs similar to ADAL's requirements.