Office365 Graph Role-Based Access Control (RBAC)

This is a variant of the Office 365 Graph service account connection for customers whose security policy forbids granting Cronofy a tenant-wide application permission. Instead of consenting to Calendars.ReadWrite across the whole tenant, the administrator authorizes Cronofy on identity alone and then scopes its access to a chosen set of mailboxes with Exchange Online Role-Based Access Control (RBAC).

You deep-link an administrator into this path. The administrator’s side of the setup is documented in the calendar admin RBAC guide; share that link with them.

Deep-linking to the RBAC path #

Start from the Enterprise Connect authorization request you already use to onboard service accounts. Pre-select the Office 365 provider with provider_name=office365 and add provider_connection_variant=rbac:

https://app.cronofy.com/enterprise_connect/oauth/authorize
    ?response_type=code
    &client_id={CLIENT_ID}
    &redirect_uri={REDIRECT_URI}
    &scope={SCOPE}
    &delegated_scope={DELEGATED_SCOPE}
    &provider_name=office365
    &provider_connection_variant=rbac
    &state={STATE}

provider_connection_variant optional  #

All other parameters are exactly as documented for the Enterprise Connect authorization request.

What the administrator experiences #

• They must sign in as a Global Administrator of the Microsoft 365 tenant. Any other account is rejected with an access_denied error, and they are returned to your redirect_uri with that error rather than a code.
• Microsoft’s admin-consent screen is not shown, because no tenant-wide permission is requested.
• They are returned to your application as with any other successful Enterprise Connect authorization, and separately complete an Exchange Online role assignment out of band to grant Cronofy access to the mailboxes they choose.

What to expect on your side #

• The service account is created before any calendar access is proven. This connection skips the directory read that normally confirms access, so a connection exists as soon as the administrator returns. Cronofy cannot read any calendar until the administrator’s Exchange role assignment has propagated and the first sync succeeds.
• Requesting delegated access to a user’s calendar before the role assignment is in place, or for a mailbox outside the administrator’s scope, will fail with impersonation_denied.
• Aside from resource listing (see below), the connection otherwise behaves like any other Graph service account: you request delegated access to a user or resource in the same way.

Resources must be authorized as accounts #

An RBAC connection is granted a scoped calendar role, not the tenant-wide Place.Read.All permission that lets Cronofy read the directory’s room and resource lists. As a result, the List Resources endpoint returns an empty list for an RBAC connection, the same as it does for a Free/Busy connection. You cannot discover a customer’s rooms and resources through Cronofy on this connection.

Instead, authorize each resource or room the same way you authorize a user: request delegated access using the resource’s email address. The administrator must include those resource mailboxes in the RBAC management scope so that Cronofy can reach them, exactly as they do for user mailboxes.

Microsoft caching #

Exchange Online does not evaluate the RBAC role assignment on every request; it caches the authorization result for a mailbox. The cache can persist anywhere between 30 minutes to 2 hours. Microsoft documents this limitation here This means:

• A newly scoped mailbox may not be reachable immediately. After the administrator adds a mailbox (user or resource) to the management scope, there may be a delay before Cronofy can access it. Delegated access requested inside that window may fail until Microsoft’s cache refreshes.
• Removing a mailbox from scope may not be immediate either. Access can persist briefly after the administrator removes a mailbox from the scope, until the cached decision expires.

If a mailbox that should be in scope is not syncing, ask the administrator to re-run the Test-ServicePrincipalAuthorization check in the RBAC guide; an InScope : True result that still will not sync usually means the cache has not yet caught up.