0

We have a multi-tenant app which has been passing in "login.windows.net/common" when creating a new AuthenticationContext. We missed the memo a while back that this had been deprecated in favor of "login.microsoftonline.com/common". The impetus for switching now is that we have customers for whom that also won't work (e.g. because they're behind "login.microsoftonline.de").

We understand the correct approach is to first query "login.microsoftonline.com/tenant-domain-name/.well-known/openid-configuration", and use the endpoints we get back, instead of hardcoding login.microsoftonline.com. What we're wondering is which of the fields we get back should be used.

I haven’t been able to find an authoritative (no pun intended) source for what the authority string should be. Some places I’ve checked:

  • The documentation for AuthenticationContext says authority is, “Address of the authority to issue token.”
  • The developer’s guide for integrating AAD with Windows Store apps references creating AuthenticationContext with an authority, doesn’t say what authority should be.
  • The sample code for a Windows Store app uses "login.microsoftonline.com/tenant".
  • The AAD docs say for multi-tenant apps, use "login.microsoftonline.com/common".
  • Other answers here on StackOverflow have ranged covered those, specific paths (like "/oauth2/token"), etc.

So, after we query the discovery service, what do we then use for authority?

  • authorization_endpoint?
  • token_endpoint?
  • map tenant_region_scope to the right login.microsoftonline.com variation, and append "/common"? or "/tenant"?

Thank you.

C. Eda
  • 11
  • 1

2 Answers2

1

The https://login.microsoftonline.com/{common-or-tenant}/.well-known/openid-configuration metadata document can be used to determine the authority URLs to log a user in (it's part of the OpenID Connect standard). Typically developers will use an OpenID Connect library or package to consume this metadata document and construct requests for them. But if you're intent on consuming it yourself, I recommend reading the OpenID Connect Discovery spec. It will instruct you that the authorization_endpoint is the URL to use to log users in.

Re: common vs. tenant. The common endpoint can be used when you don't know which company/tenant/directory the user belongs to. This is the most generic case. If you somehow know which tenant the user belongs to out of band (they work for your company, they told you in some form, etc) you can instead use the tenanted endpoint. This will direct the user directly to their company's login page, instead of performing a discovery step which locates which tenant the user belongs to.

dstrockis
  • 1,173
  • 5
  • 6
  • Thanks! We'll pass `authorization_endpoint` to ADAL since we'll already have it after discovery. And we'll look into a compatible OpenID Connect library. – C. Eda Mar 31 '17 at 20:48
  • Regarding knowing the tenant beforehand, that was part of the same workflow, i.e. we already did the discovery so we already know the tenant endpoint. – C. Eda Mar 31 '17 at 20:49
0

To sign-in for the multi-tenant app, we need to use the https://login.microsoftonline.com/common. Here is explanation from the document for your reference:

When a response returns from the /common endpoint, the issuer value in the token will correspond to the user’s tenant. It’s important to note the /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

So we need to use the common in the authorization endpoint. After that, we can get the real tenant and use the specific tenant in the token endpoint.

map tenant_region_scope to the right login.microsoftonline.com variation, and append "/common"? or "/tenant"?

What did you meant the tenant_region_scope? Based on my understanding, the scope for the multi-tenant app is same as the single tenant app. For example, the Microsoft Graph is an multi-tenant app and the scope of it you can refer here.

Below is an helpful article and code sample about multi-tenant app developing:

How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern

Build a multi-tenant SaaS web application that calls a web API using Azure AD

Fei Xue
  • 14,369
  • 1
  • 19
  • 27
  • Thanks for your response! The link "How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern" is what I was referring to when I said, "The AAD docs say for multi-tenant apps, use "login.microsoftonline.com/common"." – C. Eda Mar 30 '17 at 17:38
  • I apologize, I wasn't quite clear in my first question. I'm aware that the simple answer is to call "login.microsoftonline.com/common" (which is actually what we're doing today, since that's where our requested "login.windows.net/common" redirects). However, when I titled this, "Choosing the closest authority match", what I meant was, if we are already calling the discovery endpoint anyway, can we do *better* with the information returned? – C. Eda Mar 30 '17 at 17:38
  • Login speed is a very visible metric for us, so avoiding unnecessary redirects or lookups is valuable. After discovery, since we already *know* the user's endpoints (e.g. authorization_endpoint and token_endpoint), can we just pass those directly into AuthenticationContext for the authority URI, and speed things up? – C. Eda Mar 30 '17 at 17:38
  • Regarding tenant_region_scope, I was referring to our customers in national/sovereign clouds. So for most tenants, that's "WW", but, e.g., for some of our US government customers it will be "USG", for some German customers it will be "DE", etc. So if we can't use authorization_endpoint and token_endpoint, what I was wondering was whether we're supposed to create our own mapping: - If tenant is WW, use authority "login.microsoftonline.com/common". - If tenant is USG, use authority "login.microsoftonline.us/common". - If tenant is DE, use authority "login.microsoftonline.de/common". etc. – C. Eda Mar 30 '17 at 17:39
  • Did you mean that you want to develop an app work for the different sovereign clouds? If I understood correctly, you must have a separately registered application for that environment. An application registered in worldwide, that can call "https://login.microsoftonline.com" will generally not be able to authenticate to the other endpoints like "https://login.chinacloudapi.cn". – Fei Xue Mar 31 '17 at 06:33
  • More detail about cross sovereign clouds developing, you can refer this [thread](http://stackoverflow.com/questions/41599059/how-to-specify-a-different-aadinstance-for-a-web-api). And please feel free to let me know if I misunderstood. – Fei Xue Mar 31 '17 at 06:34
  • You only misunderstood because my information was again a bit ambiguous as I'm trying to pick up the domain vocabulary. Yes, we have an AAD multi-tenant app, but it doesn't use ADAL in any way. Instead, we have a Windows Store app that is used to connect to our AAD multi-tenant app, and it uses ADAL to acquire the necessary tokens to authenticate/authorize. So it's the Store app on an end user's device when I was wondering about how to detect which cloud to use, to reach the multi-tenant AAD app which is registered in each of those clouds. – C. Eda Mar 31 '17 at 20:32
  • And it looks like I got another answer that says yes, I can use the OpenID response to short circuit the process. Thanks for all your help! – C. Eda Mar 31 '17 at 20:32