2.2.3. Identity Providers

💡 First Principle: An identity provider (IdP) is the service that actually performs authentication and issues a signed token or assertion proving it happened — which is what lets one login be trusted by many different applications, instead of every application having to verify credentials itself.

Without a central IdP, every application would need its own username/password database, and users would need a separate password for every single app. An IdP centralizes that verification once, then issues portable proof (a token) that applications can trust without re-checking the password themselves. Microsoft Entra ID (Phase 3) is Microsoft's identity provider — it's the component that actually performs the "who are you" check that authorization decisions downstream depend on.

⚠️ Exam Trap: An identity provider issues proof of authentication; it does not, by itself, decide application-specific permissions. That authorization logic typically lives in the application or in access-management layers like RBAC (Phase 3.3.2).

Reflection Question: Why does using a single identity provider across many applications reduce the number of passwords a user has to remember, without weakening security?