OAuth-ing users not belonging to my AzureAd tenancy

Question

My company is building an email client for professionals, so far it works with Google accounts, but we would like to support Outlook365 work and school accounts as well.

We need to access emails, contact info and calendar mainly, and of course OAuth seems the right way to do that. So we registered our app on the AzureAd management portal, and started using this nice meteor package. We managed to get the OAuthentication for the 365 accounts of our company (@company.com) -although we never saw the "Grant Access?" panel-, the ones used to manage AzureAd; but any other account out of our tenancy is rejected with a 403 error "Authorization_RequestDenied" with the message "The specified credentials do no have sufficient privileges to make this request".

Is what I am trying to do possible, and if so, how can I achieve it? I could try to build a Meteor package from scratch based on the Node.js ADAL, but I would rather know if it is feasible before!

Answer 1

You need to create a multi-tenant application, or make your existing application multi-tenant. If you're doing this with OAuth, then you'll need to register URLs with the Azure Management Console (Microsoft will only allow multi-tenant applications to interact with fully registered domain names that they can confirm you own).

Register the domain in the AD Portal

When you add a domain, after entering the address, you will be prompted with a checkbox option: the phrasing is confusing. When it says "I plan to configure this domain for single sign-on with my local Active Directory," if you are planning to use single sign-on but with other Active Directories or other tenants, leave the box unchecked (so in your case, leave the box unchecked) Go through the steps to verify the domain.

Turn on Multi-Tenancy

Now, once the domain has been verified, go to the registered AD app that you want to use that domain for's configuration tab (the domain you verified must be the same as the App ID URI for the application in question): otherwise, you either need to change that app id URI, or register its domain as well – in short, the app id URI must match a domain that has been registered.

Now, switch the multi-tenant application setting to on within that application's configuration settings. You should no longer have this 400 error, assuming this is the cause and should be able to proceed with OAuth with Azure AD or Office 365 tenants not in your AD.

I'd cite more resources, but to be honest, a lot of this isn't well hashed out at all. This can provide more of an explanation, as might this MS resource.

Note: make sure to use the common endpoint for sign-in (the first link above clarifies that).