Is it supported and secure to combine SSO (delegated) and Application RBAC (app‑only Exchange Online) in a single Entra application?

Combining both delegated SSO and app‑only Exchange Online RBAC in a single Microsoft Entra application is supported and secure, and it is an expected scenario.

From the Exchange Online RBAC for Applications model:

• RBAC for Applications in Exchange Online is explicitly designed to work in addition to the unscoped permissions granted in Microsoft Entra ID. These Entra permissions can be either delegated or application permissions.
• The feature “extends the current RBAC model in Exchange Online and it replaces Application Access Policies. These permission grants are independent of the unscoped grants in Microsoft Entra ID.”
• An app can simultaneously have:
  • Delegated permissions (for example, User.Read) used for SSO and user‑driven flows.
  • Application permissions (for example, Calendars.ReadWrite) that are then further constrained in Exchange Online by RBAC for Applications (service principal + management scope + role assignment).
• The documentation explicitly describes mixed scenarios where a single app has both Microsoft Entra permissions and RBAC assignments:
  • “An app can have both Microsoft Entra consented permissions and RBAC assignments. We expect this case when an app has (for example) organization‑wide Mail.Read and scoped Mail.Send.”
  • It also walks through examples where the same app has Microsoft Entra‑consented permissions plus RBAC‑scoped permissions, and explains how the effective authorization is computed.

This shows that:

1. A single Entra application is a supported and first‑class design for:
   • Delegated SSO flows (OIDC/SAML, interactive sign‑in, public client redirect URIs), and
   • App‑only Exchange Online access controlled by RBAC for Applications (service principal, management scopes, and roles such as Application Calendars.ReadWrite).
2. RBAC for Applications is intentionally additive to Entra permissions, not a separate app model that must be isolated into a different registration.
3. The guidance does not state that SSO and Application RBAC must be separated into different app registrations. Instead, it explicitly documents scenarios where a single app has both Entra permissions and RBAC assignments and explains how they combine.

Architecturally, separating into two app registrations is an optional design choice (for isolation, lifecycle, or admin reasons), not a requirement for support or security. The supported and recommended pattern is:

• Use Microsoft Entra ID for organization‑wide or unscoped permissions (delegated and/or application).
• Use Exchange Online RBAC for Applications to add granular, resource‑scoped permissions for the same app’s service principal where needed.

This aligns with the documented model where RBAC for Applications “offers an alternate expression of authorization with an associated resource scope,” while Entra permissions (delegated or app‑only) provide the OAuth scopes and tokens.

References:

• Role Based Access Control for Applications in Exchange Online
• Authentication and authorization for the Exchange Online Admin API
• App-only authentication for unattended scripts in Exchange Online PowerShell and Security & Compliance PowerShell
• Secure hybrid access with Microsoft Entra integration