Part 1: Introduction to Microsoft Entra ID

The First Time I Encountered Azure AD

I still remember staring at the Azure portal, completely lost. My task was simple: "Add authentication to our API." But the Azure Active Directory dashboard felt like stepping into a parallel universe filled with mysterious terms like "app registrations," "service principals," and "delegated permissions."

Fast forward a few years, and I've integrated MS Entra (formerly Azure AD) into dozens of microservices, built multi-tenant SaaS platforms, and even taught teams how to navigate this identity ecosystem. That confusion I felt? It's exactly why I'm writing this series.

What Is Microsoft Entra ID?

Microsoft Entra ID is a cloud-based identity and access management (IAM) service. Think of it as the gatekeeper for your applications—it handles:

• Authentication: Verifying who users are

• Authorization: Determining what they can access

• Identity Management: Managing users, groups, and service accounts

• Single Sign-On (SSO): One login across multiple applications

• API Protection: Securing your custom APIs

The Rebrand: Azure AD → Microsoft Entra

In July 2023, Microsoft rebranded Azure Active Directory to Microsoft Entra ID. Same service, new name. You'll see both terms in documentation, APIs, and the portal. I'll use "MS Entra" or "Entra ID" throughout this series, with "Azure AD" noted where relevant.

Why Microsoft Entra ID?

When I started building enterprise applications, I initially considered rolling my own authentication. Bad idea. Here's why MS Entra won:

1. Enterprise Integration

Most enterprises already use Microsoft 365, which means they have Entra ID. Integrating your app means:

• Users sign in with their work accounts

• No new usernames/passwords to remember

• IT administrators manage access centrally

2. Security at Scale

MS Entra provides enterprise-grade security:

• Multi-factor authentication (MFA)

• Conditional Access policies

• Anomaly detection and threat protection

• Compliance certifications (SOC 2, ISO 27001, etc.)

3. Developer-Friendly

Once you understand it, MS Entra is actually quite developer-friendly:

• Well-documented REST APIs

• SDKs for major languages

• OAuth 2.0 and OpenID Connect support

• Microsoft Graph API for accessing user data

4. Scalability

MS Entra handles billions of authentications daily. Your app can scale from 10 to 10 million users without changing authentication logic.

Core Concepts

Let me break down the fundamental concepts. These confused me initially, but understanding them is crucial.

Tenant

A tenant is an instance of Entra ID. Think of it as an organization's dedicated identity space.

Example from my experience:

• My company has a tenant: mycompany.onmicrosoft.com

• Every employee gets an account in this tenant: [email protected]

• All apps registered in this tenant inherit its policies

Key points:

• Each tenant has a unique ID (GUID)

• Tenants are isolated from each other

• One organization typically has one tenant (but can have multiple)

Directory

A directory is essentially the database within a tenant that stores:

• Users

• Groups

• Applications

• Service principals

• Policies

In practice, "tenant" and "directory" are often used interchangeably. The tenant is the container; the directory is what's inside.

Users

Users are human identities. There are several types:

Cloud-Only Users

Created directly in Entra ID.

// Example: User object structure
interface EntraUser {
  id: string;                    // Unique ID (GUID)
  userPrincipalName: string;     // [email protected]
  displayName: string;           // John Doe
  mail: string;                  // [email protected]
  accountEnabled: boolean;       // true/false
}

Synced Users

Synchronized from on-premises Active Directory using Azure AD Connect.

Guest Users (B2B)

External users invited to your tenant. These were crucial when I built a multi-tenant POS system where different companies needed to collaborate.

// Guest user example
{
  id: "abc123...",
  userPrincipalName: "[email protected]#EXT#@mycompany.onmicrosoft.com",
  userType: "Guest"
}

Groups

Groups organize users and manage permissions at scale.

Types of groups:

1. Security Groups: Control access to resources

2. Microsoft 365 Groups: Collaboration groups (email, SharePoint, Teams)

Example from my payment service:

// Group-based access control
const groups = {
  finance: "aa11bb22-...",      // Can approve payments
  support: "cc33dd44-...",      // Can view transactions
  admin: "ee55ff66-..."         // Full access
};

// Check if user is in finance group
if (userGroups.includes(groups.finance)) {
  // Allow payment approval
}

Applications

An application in Entra ID represents your software that needs authentication.

When you register an app, you get:

• Application ID (Client ID): Unique identifier

• Client Secret (for confidential apps): Password for your app

• Redirect URIs: Where users return after authentication

Example: My microservices architecture has different app registrations:

• payment-api (backend API)

• user-service (backend API)

• pos-frontend (React SPA)

• mobile-app (React Native)

Each has its own app registration with specific configurations.

Service Principals

A service principal is like a user account for applications. When you register an app, a service principal is automatically created in your tenant.

Think of it this way:

• App Registration: The blueprint (exists once globally)

• Service Principal: The instance (exists per tenant)

Analogy: App registration is like a "class" in programming; service principal is the "instance."

This distinction matters for multi-tenant apps. One app registration can have service principals in multiple tenants.

Enterprise Applications

Enterprise applications are pre-built integrations available in the Azure marketplace. Examples:

• Salesforce

• GitHub

• ServiceNow

• Slack

When you add one, Entra ID creates a service principal for that app in your tenant.

My experience: I added GitHub as an enterprise app so employees could sign in to GitHub with their company credentials. The service principal managed this SSO connection.

Managed Identities

Managed identities are special service principals for Azure resources. They eliminate the need to manage credentials.

Two types:

1. System-Assigned: Tied to a specific Azure resource (VM, App Service, Function)

2. User-Assigned: Standalone identity that can be assigned to multiple resources

Example from my Azure Functions:

// Function with system-assigned managed identity
// Automatically gets credentials to access Key Vault
// No secrets in code!

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

const credential = new DefaultAzureCredential(); // Uses managed identity
const vaultUrl = "https://my-vault.vault.azure.net";
const client = new SecretClient(vaultUrl, credential);

const secret = await client.getSecret("database-connection-string");

No API keys, no connection strings in environment variables. The managed identity handles authentication automatically.

Entra ID Architecture

Let me show you how these concepts fit together:

┌─────────────────────────────────────────────────────────┐
│          Entra ID Tenant (mycompany.onmicrosoft.com)   │
│                                                         │
│  ┌─────────────────────────────────────────────────┐  │
│  │              Directory                          │  │
│  │                                                 │  │
│  │  Users:                                         │  │
│  │  - [email protected]                          │  │
│  │  - [email protected]                          │  │
│  │  - [email protected]#EXT#                      │  │
│  │                                                 │  │
│  │  Groups:                                        │  │
│  │  - Finance Team                                │  │
│  │  - Engineering Team                            │  │
│  │                                                 │  │
│  │  App Registrations:                            │  │
│  │  - payment-api (client ID: abc123...)         │  │
│  │  - pos-frontend (client ID: def456...)        │  │
│  │                                                 │  │
│  │  Service Principals:                           │  │
│  │  - payment-api SP                              │  │
│  │  - pos-frontend SP                             │  │
│  │  - GitHub Enterprise SP                        │  │
│  │                                                 │  │
│  │  Managed Identities:                           │  │
│  │  - payment-function-identity                   │  │
│  │  - api-gateway-identity                        │  │
│  └─────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────┘

                         ↓
                    
    ┌──────────────┐       ┌──────────────┐       ┌──────────────┐
    │   Frontend   │       │  Backend API │       │ Azure Function│
    │     App      │       │              │       │  (Managed ID) │
    └──────────────┘       └──────────────┘       └──────────────┘
         │                       │                       │
         │ Authenticate          │ Validate Token        │ Access Key Vault
         │ (OAuth flow)          │ (JWT validation)      │ (No credentials)
         ↓                       ↓                       ↓
    Access Token           Authorize Request      Retrieve Secrets

Identity Types in Detail

1. Users (Human Identities)

When to use: Any time a human needs to interact with your application.

My usage:

• Employees accessing internal tools

• Customers using our SaaS platform

• Partners collaborating on projects

2. Service Principals (Application Identities)

When to use: Service-to-service communication, automated processes.

My usage:

// CI/CD pipeline authenticating to deploy
// payment-service calling user-service
// Scheduled job accessing database

// Example: Service principal auth
import { ClientSecretCredential } from "@azure/identity";

const credential = new ClientSecretCredential(
  process.env.TENANT_ID!,
  process.env.CLIENT_ID!,
  process.env.CLIENT_SECRET!
);

const token = await credential.getToken("https://graph.microsoft.com/.default");
// Use token to call Microsoft Graph API

3. Managed Identities (Azure Resources)

When to use: Your code runs on Azure (App Service, Functions, VMs, AKS).

My usage:

• Azure Functions accessing Key Vault

• App Service connecting to Azure SQL

• AKS pods calling Azure Storage

Why they're amazing: Zero credential management. Azure handles everything.

4. Guest Identities (External Users)

When to use: External users need access to your resources.

My B2B scenario:

// Invite external user
POST https://graph.microsoft.com/v1.0/invitations
{
  "invitedUserEmailAddress": "[email protected]",
  "inviteRedirectUrl": "https://myapp.com",
  "sendInvitationMessage": true
}

// They get email → accept invitation → access your app

Common Scenarios

Let me show you how these concepts apply to real scenarios:

Scenario 1: Internal Web App

Setup:

• Employees sign in with [email protected]

• App uses authorization code flow

• Group membership determines permissions

Components:

• Users: Employee accounts

• App registration: Web app

• Groups: Finance, Engineering, Admin

Scenario 2: Microservices Architecture

Setup:

• Frontend SPA authenticates users

• Backend APIs validate tokens

• Services communicate with service principals

Components:

• Users: End users

• App registrations: Frontend + multiple backend APIs

• Service principals: For inter-service auth

• Managed identities: For Azure resource access

Scenario 3: Multi-Tenant SaaS

Setup:

• Multiple customer organizations

• Each customer has their own Entra tenant

• Your app works across all tenant

Components:

• App registration: Multi-tenant enabled

• Service principals: One per customer tenant

• Users: From different customer tenants

Navigating the Azure Portal

Let me guide you through the portal where I spent countless hours initially confused.

Accessing Entra ID

1. Portal: https://portal.azure.com

2. Search: "Microsoft Entra ID" or "Azure Active Directory"

3. You'll see the overview dashboard

Key Portal Sections

Microsoft Entra ID Dashboard
├── Overview: Tenant info, basics
├── Users: Manage user accounts
├── Groups: Create and manage groups
├── Enterprise applications: SSO integrations
├── App registrations: Your custom apps
├── Roles and administrators: Admin roles
└── Security: Conditional Access, MFA, etc.

Important Settings

Tenant Properties:

• Tenant ID (you'll need this in code)

• Tenant name

• Primary domain

Licenses:

• Free: Basic features

• P1: Conditional Access

• P2: Identity Protection, PIM

Most dev work can be done with the free tier.

Your First Steps

Here's what I wish someone had told me on day one:

Step 1: Understand Your Tenant

Find your tenant information:

# Tenant ID: In Azure Portal → Entra ID → Overview
TENANT_ID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Tenant Name
TENANT_NAME="mycompany.onmicrosoft.com"

Step 2: Register an App

We'll do this in Part 2, but here's the preview:

1. Azure Portal → Entra ID → App registrations

2. New registration

3. Name your app

4. Choose account types (single tenant vs multi-tenant)

5. Set redirect URI

6. Get your Client ID

Step 3: Create a Test User

1. Azure Portal → Entra ID → Users

2. New user

3. Set username and temporary password

4. Use this for testing authentication flows

Common Misconceptions

Let me clear up confusion I had (and see others have):

Misconception 1: "Azure AD is just for Microsoft 365"

Reality: While it powers M365, Entra ID is a full IAM platform for any application. I use it for custom Node.js APIs, Python services, React SPAs—anything that needs auth.

Misconception 2: "I need Azure resources to use Azure AD"

Reality: You can use Entra ID without running anything on Azure. Your app can be on AWS, GCP, on-prem, anywhere. Entra ID is just the identity provider.

Misconception 3: "App registration and service principal are the same thing"

Reality: They're related but different:

• App registration: Global definition of your app

• Service principal: Instance of your app in a specific tenant

Misconception 4: "I need to store tokens in my database"

Reality: Never store access tokens in databases. They're short-lived (usually 1 hour) and meant to be held in memory or secure storage. Refresh tokens can be stored encrypted if needed.

Key Takeaways

1. Entra ID = Identity as a Service: Outsource authentication complexity to Microsoft

2. Tenants = Organizations: Each organization has its own isolated identity space

3. Multiple Identity Types: Users, service principals, managed identities—each serves different purposes

4. App Registration ≠ Service Principal: One defines your app, the other is the instance per tenant

5. Start Small: You don't need to understand everything to get started

What's Next

In Part 2: Applications and Service Principals, we'll:

• Register your first application

• Understand app registration settings

• Create and manage service principals

• Configure multi-tenant applications

• Generate client secrets and certificates

We'll move from theory to hands-on configuration, setting up everything you need for authentication in your applications.

---

Next: Part 2: Applications and Service Principals Back to Series Overview