Entra ID

Microsoft Entra ID (formerly Azure AD) is the identity plane for humans and applications: tenants, app registrations, OAuth 2.0 and OpenID Connect flows, managed identities for Azure resources, groups, roles, and Conditional Access policies.

| Identity type | Typical use | |---------------|-------------| | User | Interactive sign-in to apps and portals | | App registration | Confidential or public client OAuth flows | | Managed identity | Workload access to Key Vault, Storage, SQL | | Service principal | Automation and CI/CD with scoped roles |

					Authorization code + PKCE (SPA) → access token → call API with Bearer header
Client credentials (daemon) → app-only token → least-privilege app role
				

On interviews: authorization code with PKCE for SPAs; client credentials for backend jobs; managed identity versus stored secrets; Conditional Access (MFA, compliant device); and how you would audit excessive Directory.Read.All grants.

Common pitfalls: long-lived client secrets in repos; admin consent granted too broadly; confusing app roles with Azure RBAC; and using the same app registration across unrelated products.

The trade-off is centralized enterprise identity and SSO versus configuration complexity, tenant lock-in, and the blast radius of mis-scoped permissions.

Checklist:

• Prefer managed identity and certificate credentials over secrets.
• Scope app permissions to least privilege with admin review.
• Separate app registrations per product boundary.
• Enable sign-in and audit logs with retention.
• Test Conditional Access impact on CI and service accounts.