Get shared calendar from different user(meeting room)

Question

// How to get different user / meeting room calendar events?

We are trying with the graph REST API to get calendar events of another user (shared calendar to the authenticated user) or a meeting room (should be an Active Directory user with shared calendar to all users within the organization).

We still get "Forbidden" response.

We can successfully get the user(himself) authenticated calendar events.

We can also get user details of the authenticated user and even of another user (user authenticated as [email protected] and can get user details of [email protected]) but we cannot get details of the meeting room user even though it should be a normal user in our AD.

We tried to setup all delegated and even app permission scopes, nothing helped.

Example: var endpoint = "https://graph.microsoft.com/v1.0/users/"+userId+"/calendarView";

Is there a way to retrieve this information?

Answer 1

The problem is that your token does not have the correct scope. To be able to access shared calendars, you need the Calendars.Read.Shared (or Calendars.ReadWrite.Shared). How you get that scope into your token depends on where you registered the app (which answers your first question!)

1. Does it matter where or how the application was registered?

   Yes, this matters. Both methods will work, but where you register affects how you request authorization and tokens. Also, apps registered in Azure Management Portal can only authenticate Office 365 users, not Outlook.com users. More on this in #2.

2. Does it matter what authentication URL we use?

   Yes! The URL you use is directly related to which place you registered your app. I'm going to break this down below.

3. App scope permissions vs delegated scope permissions - does it matter which ones we set up in the application? Will our desired functionality work with delegated permissions?

   Yes it matters. App permissions are granted to the app, and for Outlook APIs, these are global to the entire organization. So if you grant an app Mail.Read, it can read mail for all users in the org. The app acts as itself, and does not authenticate a user. Because of this, the auth method requires a certificate instead of a client secret. This method is meant for daemon-type apps. You most likely want delegate permissions since you want to authenticate users and then give them access to just those other mailboxes/calendars they are allowed to view.

4. Do AD permissions somehow influence the permissions user has in the application?

   Well yes, in the sense that if you include a .Shared scope in your permissions, what the user has access to is set by what other users have shared with them (and this ties back to AD).

How do I add a shared scope

As I said above, this matters on how you registered your app.

Azure Management Portal

Apps registered in the Azure Management Portal use the "v1" version of Azure's OAuth2 implementation. Under this model, you have to specify the permissions for your app "up front" on the app registration itself. To add a shared permission, you have to modify the app registration in the portal. The permissions are shown in the portal as "Read user and shared calendars" (for Calendars.Read.Shared) and "Read and write user and shared calendars" (for Calendars.ReadWrite.Shared).

If your app is registered here, then you MUST use the v1 auth and token endpoints:

https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token

Additionally, under the v1 scheme, if you add new scopes to your app registration, you MUST have the user's reconsent. Otherwise, the next time they sign in to your app, they will just get the same permissions they had before. To do this, when sending the users to the authorize endpoint, add a prompt=consent parameter to the authorize URL.

Application Registration Portal

Apps registered here use the v2 Azure implementation and gain a few benefits. First, you can authenticate Microsoft accounts (Outlook.com) as well as Office 365 users. Second, adding scopes doesn't require modifying your app registration. And last, you don't have to manually reconsent users, the auth endpoint will detect the change and prompt for you.

Apps registered here use the v2 auth and token endpoints:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Scopes are specified in the scope URL parameter in the auth endpoint. So to add the shared scopes, you would just replace your existing Calendars.Read and/or Calendars.ReadWrite with the .Shared equivalent.