MSAL: Support login of non-work accounts to be able to perform Azure actions

Question

I want to allow people to use some deployments tools to perform actions in their Azure environments.

We currently have a working MSAL.js solution for supporting work accounts to be able to login and acquire the scope https://management.azure.com/user_impersonation using an AAD app.

To move to supporting non-work accounts we:

1. Verified our application is set to allow all types of accounts
2. Changed the endpoint used for logins from /organizations to /common

Unfortunately despite the /common it says we need to use a work or school account when we provide something like an @gmail account.

Without being able to acquire a permission scoped to this API we can't list tenants someone has access to so that we can proceed. It seems really backward & poor UX to have a workaround of needing their tenant ID to be manually provided and changing the our login endpoint. Prior we simply made the assumption that it's whatever tenant their AAD account is part of but a default login acquisition only returns the tenant id of the app.

Reproducible example You can see this behaviour with a Microsoft demo application.

OpenID works with a personal email

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=openid&state=12345

Azure scope does not work

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6731de76-14a6-49ae-97bc-6eba6914391e&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F&response_mode=query&scope=https://management.azure.com/user_impersonation&state=12345

What is the right combination of login endpoints and scopes (or multiple steps!) needed to be able to support user impersonation of non-work accounts for acting in Azure?

PS Older Q in a similar vein indicates this may not be possible which is exceedingly frustrating.

Answer 1

Make sure that your AAD application (6731de76-14a6-49ae-97bc-6eba6914391e) is registered as "Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)".

You can also switch the existing AAD application to this type by modifying the manifest file: set "signInAudience": "AzureADandPersonalMicrosoftAccount".

This will allow personal account to sign in.

UPDATE:

Sorry my bad. Azure resources should be only available to work account. Personal account cannot access Azure resources because it doesn't have Azure subscription. When a personal account is added into a tenant as the guest, it will be treated as work account.

If you click on the Try it -> Sign in in this page, you will be redirected to this url: https://login.microsoftonline.com/common/oauth2/authorize?client_id=7f59a773-2eaf-429c-a059-50fc5bb28b44&redirect_uri=https%3a%2f%2ftoken.docs.microsoft.com%2fsignin-oidc&resource=https%3a%2f%2fmanagement.core.windows.net%2f&response_type=code+id_token&******************.

This is v1.0 endpoint which doesn't support personal account.

So for v2.0 endpoint, if you set AAD application type as Accounts in any organizational directory (Any Azure AD directory - Multitenant) or Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) and use organizations or common endpoint, it will treat your account as a personal account by default, thus preventing you from logging in.

Currently the only way to implement it is to use v1.0 endpoint like this:

https://login.microsoftonline.com/common/oauth2/authorize?client_id=19xxxxxx-68ed-433c-a2c5-5f5cxxxxxx05&response_type=code&redirect_uri=https://localhost/&response_mode=query&resource=https://management.azure.com/&state=12345

Remember to specify the AAD application as Accounts in any organizational directory (Any Azure AD directory - Multitenant) to avoid the account being recognized as a personal account.