Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder
intermediate 8 mins Read

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.