Understanding Microsoft Entra ID Tenants
How Entra ID tenants, directories, app registrations, and conditional access policies work for enterprise identity management.
Last reviewed: July 27, 2026
Introduction
Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud-based identity and access management (IAM) service. Every Microsoft 365 subscription and Azure account is backed by an Entra ID tenant — an isolated directory instance containing users, groups, devices, and application registrations for an organization. Unlike on-premises Active Directory (domain-joined PCs, Kerberos, Group Policy), Entra ID is cloud-native: it uses modern protocols (OIDC, SAML 2.0, OAuth 2.0) and is accessible from any device with internet access.
Step-by-Step: Key Tenant Concepts
flowchart TD
A["1. Tenant Architecture"]
B["2. App Registration (OAuth 2.0 Client)"]
C["3. Authentication Flow"]
D["4. Conditional Access Policies"]
E["5. B2B Guest Access"]
A --> B
B --> C
C --> D
D --> E
Step 1: Tenant Architecture
Entra ID Tenant (contoso.onmicrosoft.com / Tenant ID: 9abc-1234-...)
├── Users and Groups
│ ├── alice@contoso.com (Member user)
│ ├── bob@partner.com (Guest B2B user)
│ └── Engineering Group
├── App Registrations
│ ├── My API Backend (Client ID: aaaa-1111)
│ └── My SPA Frontend (Client ID: bbbb-2222)
├── Enterprise Applications (Service Principals)
├── Devices (Azure AD Joined, Hybrid Joined)
└── Conditional Access Policies
Step 2: App Registration (OAuth 2.0 Client)
To enable any application to authenticate via Entra ID, you must create an App Registration:
# Register an application (via Azure CLI)
az ad app create --display-name "My API Backend" --sign-in-audience "AzureADMyOrg" --web-redirect-uris "https://api.example.com/auth/callback"
# Add required API permissions (Microsoft Graph: User.Read)
az ad app permission add --id <app-client-id> --api 00000003-0000-0000-c000-000000000000 # Microsoft Graph
--api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope # User.Read
# Create a client secret
az ad app credential reset --id <app-client-id>
Step 3: Authentication Flow (Authorization Code + PKCE)
// MSAL.js (Microsoft Authentication Library) handles this flow
import { PublicClientApplication } from "@azure/msal-browser";
const msalInstance = new PublicClientApplication({
auth: {
clientId: "bbbb-2222", // App Registration Client ID
authority: "https://login.microsoftonline.com/9abc-1234", // Tenant ID
redirectUri: "https://app.example.com"
}
});
// Initiate login
const loginRequest = {
scopes: ["openid", "profile", "User.Read"]
};
msalInstance.loginPopup(loginRequest).then(result => {
// result.accessToken: JWT for calling APIs
// result.idToken: user identity claims
console.log("Signed in as:", result.account.username);
});
Step 4: Conditional Access Policies
Conditional Access (CA) is Entra ID’s policy engine — it evaluates signals (who, what device, which app, where, what risk level) and applies access controls:
Policy: "Require MFA for admin portal access from non-compliant devices"
Assignments:
Users: Members of "IT Admins" group
Cloud apps: Admin Portal application
Conditions: Device compliance = NOT compliant OR
Sign-in risk = Medium or High
Access controls:
Grant: Require multi-factor authentication
Session: Sign-in frequency: every 8 hours
Common CA policy patterns:
- Block legacy authentication (SMTP, POP3, IMAP — no MFA support)
- Require compliant device for corporate data access
- Require MFA for all external access
- Block sign-in from high-risk countries (named locations)
Step 5: B2B Guest Access
Entra ID B2B allows external partners to access your apps using their own identity:
# Invite a guest user from partner organization
az ad user invite --invited-user-email-address alice@partner.com --invite-redirect-url "https://myapp.example.com" --display-name "Alice Partner"
# Guest user authenticates with their own IdP (partner.com's Entra ID/Google)
# Entra ID federates and issues tokens for your tenant's resources
# No password management on your side
Key Takeaways
- An Entra ID tenant is an isolated directory — a unique Tenant ID (GUID) identifies your organization’s directory globally.
- App Registrations define the OAuth 2.0 client for each application — one registration per application, with client IDs and secrets.
- Conditional Access policies are the primary tool for enforcing Zero Trust — they evaluate context (device, location, risk) before granting access.
- Use Microsoft Authentication Library (MSAL) for all authentication flows — it handles token caching, refresh, and the PKCE flow automatically.
- B2B guest access allows external users to authenticate with their home IdP — no separate account or password management required on your side.
Historical figures, architectures, and capabilities are for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Research papers, developer documentation.