The tenant: logical boundary and central repository
Microsoft Entra ID (formerly Azure Active Directory) organizes identity around a fundamental unit: the tenant. This isolated instance hosts three types of root objects:
- Users: the human identities of the organization.
- Groups: aggregates of accounts used to streamline rights assignment.
- Applications: the services and software that delegate their authentication to the tenant.
Every access decision stems from these three objects. The tenant represents both the security boundary and the trust repository of the organization in the Microsoft cloud.
Tenant Isolation
Each tenant is logically isolated from others. An object defined in one tenant is not visible or accessible from another tenant without an explicit collaboration mechanism (B2B or B2C).
Authentication: supported protocols
Authentication answers the question "who are you?". Microsoft Entra ID supports three standard protocols:
- OAuth 2.0: authorization delegation between applications and services.
- OpenID Connect (OIDC): federated identity layer built on OAuth 2.0, used for modern sign-ins.
- SAML: single sign-on (SSO) with legacy enterprise applications.
The choice of protocol depends on the type of application to integrate. OIDC is preferred for new integrations; SAML remains necessary for applications that do not yet support OAuth 2.0.
Authorization: RBAC and principle of least privilege
Authorization answers the question "what are you allowed to do?". It is based on Azure RBAC (Role-Based Access Control), with role assignment by scope (scope assignment) at three levels:
- Subscription
- Resource Group
- Individual Resource
The most common built-in roles are Owner, Contributor and Reader. This hierarchical model allows applying the principle of least privilege: granting only the necessary rights, at the most restrictive level possible.
Custom Roles
Azure RBAC supports custom roles when built-in roles do not precisely cover the need. Their creation requires Microsoft.Authorization/roleDefinitions/write rights on the target scope.
Security layer: conditional access, MFA and PIM
Beyond authentication and authorization, Microsoft Entra ID integrates a contextual security layer composed of three mechanisms:
- Conditional Access: applies policies based on context — location, device compliance, risk level calculated by Microsoft Entra ID Protection.
- MFA (Multi-Factor Authentication): strengthens identity verification with a second factor.
- Privileged Identity Management (PIM) and Privileged Identity Groups (PIG): govern privileged access over time via on-demand activation (just-in-time), reducing the exposure surface of admin accounts.
Required Licenses
Conditional Access and PIM require a Microsoft Entra ID P2 license (included in Microsoft Entra ID Governance, or via Microsoft 365 E5). Without this license, conditional access policies cannot be created or applied.
Non-human identities: managed identities and service principals
Automation and CI/CD pipelines rely on non-human identities. Microsoft Entra ID offers several types:
| Type | Primary Usage | Secret Management |
|---|---|---|
| Managed Identity (System-Assigned) | Individual Azure resource | No secret to manage |
| Managed Identity (User-Assigned) | Shared between multiple resources | No secret to manage |
| Service Principal | External applications and scripts | Secret or certificate with rotation |
| App Registration | Application registration in the tenant | Secret or certificate with rotation |
| Enterprise Application | Local instance of an app in the tenant | Inherits from App Registration |
Managed identities should be prioritized for resources hosted in Azure: they eliminate the storage of secrets in code or pipelines. Service principals remain necessary for scenarios outside Azure or multi-tenant.
External access: B2B and B2C
Microsoft Entra ID manages two scenarios for opening to the outside:
- Azure AD B2B (Business-to-Business): enables inter-organizational collaboration. A user from a partner tenant is invited as a "guest" in your tenant, without creating a local account.
- Azure AD B2C (Business-to-Consumer): designed for consumer scenarios, it manages millions of external customer identities with customizable sign-up and sign-in flows. B2C is a separate service, configured in a dedicated tenant.
B2B vs B2C
B2B addresses collaboration with partner organizations; B2C addresses applications intended for end-user consumers. The two mechanisms do not share the same tenant infrastructure.
Zero Trust Architecture: consistency across layers
The architecture of Microsoft Entra ID is natively part of the Zero Trust model: no implicit trust is granted, whether to a user, device or service. Each layer — authentication, authorization, contextual security, machine identities and external access — constitutes an independent control point.
For architects and administrators, mastery of this articulation is the prerequisite for any secure environment design. Architecture decisions made at the tenant level (group structure, RBAC scopes, conditional access policies) have direct repercussions on the security posture of the entire organization.
Key points to remember
- The tenant is the logical boundary of identity: users, groups and applications are its root objects.
- OAuth 2.0 / OIDC / SAML cover the full range of modern and legacy authentication scenarios.
- Azure RBAC applies least privilege through hierarchical scopes.
- Conditional Access and PIM require Microsoft Entra ID P2.
- Managed identities eliminate secrets in automated workflows.
- B2B manages inter-organizational collaboration; B2C manages external customer identities.
