Azure Active Directory Users and SaaS Application using Microsoft Graph Api

Question

I am developing a SaaS application that requires external organizations' AD users to sync appointments to Office 365 calendar event.

Admin user scenario:

1. Admin imports all AD Users to the app.
2. The app redirects the admin to Microsoft login and request permissions.
3. Admin allows the app to access users' calendars.

Normal usersScenario:

1. User logs in to the app.
2. User creates an appointment and sync to Office 365 Calendar (without asking for permissions).

I'm using the following endpoints in Microsoft Graph API:

Authority = "https://login.microsoftonline.com/common/oauth2/authorize"
Resource = "https://graph.microsoft.com/"

If I wanted to give normal users access to their Microsoft data, do I need to change the tenant "common" to their tenant ids?

My other question is how does admin consent work based on my scenarios?

Answer 1

First, I recommend against importing all users to your app. It is best to only provision the users you actually need, in a "just in time" manner as they sign in. If your app has scenarios where it's useful to list other users in the tenant (e.g. a "people picker"), you can use the Microsoft Graph API on-demand.

Next, to answer one of your questions: No, you should not switch the Authority endpoint to the tenant-specific endpoint. Keep using the common endpoint, which ensure you can authenticate any user from any tenant.

Admin consent can be requested explicitly, by making use of the prompt=admin_consent query parameter during the authentication request. One approach is for your app to perform a regular sign-in, and then, once the user is signed in, uses the Microsoft Graph API to check if the user is a tenant admin. If they are, you can redirect them to re-authenticate, but this time with the prompt=admin_consent option. Alternatively, you can have a "sign-up" flow for your application that uses prompt=admin_consent from the beginning (with the appropriate note that only tenant administrators can do that, since non-admins will get an error from Azure AD that they might not understand).