So far in my previous posts I’ve discussed signing into an application using Azure Active Directory (Azure AD) using a basic application registration in Azure AD. Last post we added some additional permissions that required administrator consent. However, up until now, only users in the same directory (aka tenant) that the application is registered in, can sign in. In the case of the sample application I’ve been working with, the application is registered to the nicksdemodir.onmicrosoft.com tenant, so only users belonging to that tenant can sign in eg admin@nicksdemodir.onmicrosoft.com. If I attempt to sign in with an account from a different tenant, I run into a few issues, and depending on what type of account I sign in with, the error that is displayed varies.
I’ll start by signing in with a regular user account that belongs to a different tenant (in this case btro365dev.onmicrosoft.com). When I attempt to sign in with this account, everything seems to go well – I’m prompted to sign in; I successfully sign in; I’m returned to the application where the code is exchanged for an access token. However, when I attempt to use this access token I get a rather cryptic error about an “Unsupported token” eg:
{“odata.error”:{“code”:”Request_BadRequest”,”message”:{“lang”:”en”,”value”:”Unsupported token. Unable to initialize the authorization context.”},”requestId”:”86481ea2-79bd-461b-93ad-4f649286617a”,”date”:”2017-01-25T21:28:14″}}
This is actually less cryptic than it seems – essentially it’s saying that I’m attempting to present a token that the API can’t process. If you were to open the access token in https://jwt.io, you’d see that the token has been issued by the nicksdemodir.onmicrosoft.com tenant (actually you’d see the STS url that correlates to this tenant) for an account that doesn’t exist in that tenant (eg testuser@btro365dev.onmicrosoft.com). Whilst this is a legitimate access token, when you present it to the Graph API, it attempts to retrieve information about the user in the issuing tenant, which of course fails, since the user doesn’t exist there.
Ok, let’s see what happens if I attempt to launch the admin consent prompt. In this case, after I sign in (now using admin@btro365dev.onmicrosoft.com which is a global administrator) I get a more useful error message saying “AADSTS50020: User account … does not exist in tenant”.
The reason this error message is useful is that it prompts me to think about what I’m attempting to do – I’ve been prompting the user to sign into the nicksdemodir.onmicrosoft.com tenant, which is fine if I’m a user that belongs to that tenant but since I’m attempting to use a different user, this is clearly not correct. So, the first step in making my application multi-tenanted is to change the authorization url that I’m directing the user to in order to sign in, to one that is more generic and will allow signing in by users from any tenant. This involves exchanging the “nicksdemodir.onmicrosoft.com” with “common” in the url – the following code shows how I adapted the code in my sample application to support urls that are single tenanted (ie AuthorizationUrl and AdminConsentUrl) as well as the multi-tenanted equivalent (ie MultiTenantAuthorizationUrl and MultiTenantAdminConsentUrl).
private string BaseAuthorizationUrl =>
“https://login.microsoftonline.com/{0}/oauth2/authorize?” +
“client_id=40dba662-4c53-4154-a5cf-976473306060&” +
“response_type=code&” +
“redirect_uri=sample://callback&” +
“nonce=1234&” +
“resource=https://graph.windows.net”;private string AuthorizationUrl => string.Format(BaseAuthorizationUrl, “nicksdemodir.onmicrosoft.com”);
private string AdminConsentUrl => $”{AuthorizationUrl}&prompt=admin_consent”;
private string MultiTenantAuthorizationUrl => string.Format(BaseAuthorizationUrl, “common”);
private string MultiTenantAdminConsentUrl => $”{MultiTenantAuthorizationUrl}&prompt=admin_consent”;
For example:
Authorization url: https://login.microsoftonline.com/nicksdemodir.onmicrosoft.com/oauth2/authorize?client_id=40dba662-4c53-4154-a5cf-976473306060&response_type=code&redirect_uri=sample://callback&nonce=1234&resource=https://graph.windows.net
Multi-tenant authorization url: https://login.microsoftonline.com/common/oauth2/authorize?client_id=40dba662-4c53-4154-a5cf-976473306060&response_type=code&redirect_uri=sample://callback&nonce=1234&resource=https://graph.windows.net
Attempting to sign in using the multi-tenant authorization url with an account that doesn’t belong to the nicksdemodir.onmicrosoft.com tenat now yields the following error:
This error seems to be correct, considering the application registration exists in the nicksdemodir.onmicrosoft.com tenant. Unfortunately it’s not very clear what you need to do in order to fix this issue – you can’t add the application to the btro365dev.onmicrosoft.com tenant, and even if you could, you wouldn’t want to have to manually do that for every tenant that you want to support. Luckily, there is a mechanism that allows Azure AD to essentially add the application to new tenants on an as required basis (similar to how applications are added to a users list of applications at https://myapps.microsoft.com as they consent to use of the application). In order for Azure AD to do this, the application registration has to be configured to support multiple tenants. Click on the Manifest button for the application registration in Azure AD – the property “availableToOtherTenants” should be set to true (default is false).
Now when we attempt to sign in (again with a non-global administrator user) we see a familiar error saying that the calling principal (ie the signed in user) doesn’t have permissions.
We know how to fix this from my previous post, the only difference is that we need to direct the user to the multi-tenant admin consent url eg
https://login.microsoftonline.com/common/oauth2/authorize?client_id=40dba662-4c53-4154-a5cf-976473306060&response_type=code&redirect_uri=sample://callback&nonce=1234&resource=https://graph.windows.net&prompt=admin_consent
The global administrator, after signing in, will again see the admin consent prompt – it’s worth pointing out here that it lists both the directory the user is signed into (ie BTR Office Dev – btro365dev.onmicrosoft.com) and the tenant that the application is published (ie registered) in (ie DemoDirectory – nicksdemodir.onmicrosoft.com).
Again, consenting will enable all users in the foreign tenant (ie btro365dev.onmicrosoft.com) to then access the application via the multi-tenant authorization url.
There is one last adjustment that has to be made, and that’s to the Token url. When exchanging the code for an access token, it’s important that the token url is also adjusted to be either single or multi-tenant. Previously the url included the tenant that the application was registered to ie nicksdemodir.onmicrosoft.com. This needs to be changed in the multi-tenant scenario to use “common”. In order to allow authorization to occur for both single and multi-tenant scenarios within the application, I needed a way to dynamically control the token url based on whether the user signed in via the single tenant or multi-tenant authorization url. Currently, all we get back when the user has signed in is a code which we need to exchange for an access token. Luckily, we can pass an additional parameter, “state,” into the authorization url, which will get passed back to the application along with the code – we can use this to determine which authorization url was used. I’m only going to adjust the multi-tenant authorization url as the application will treat the lack of state parameter to mean that the user was directed to the single tenant authorization url.
private string MultiTenantAuthorizationUrl => string.Format(BaseAuthorizationUrl, “common”) + “&state=multi”;
private string MultiTenantAdminConsentUrl => $”{MultiTenantAuthorizationUrl}&prompt=admin_consent”;
Now, the token url is updated based on the state parameter value:
private string BaseTokenUrl => “https://login.microsoftonline.com/{0}/oauth2/token”;
private string TokenUrl(bool isMulti)
{
return string.Format(BaseTokenUrl, isMulti ? “common” : “nicksdemodir.onmicrosoft.com”);
}var isMulti = uri?
.Split(‘?’).Skip(1).FirstOrDefault()?
.Split(‘&’).Select(q => q.Split(‘=’))
.Where(x => x.Length == 2 && x[0] == “state”)
.Select(x => x[1])
.FirstOrDefault() == “multi”;var tokenUrl = TokenUrl(isMulti);
And that’s it – a user can sign in from any tenant (assuming the global administrator has signed in an consented) and retrieve information from the Azure Graph API.