1.4.1. OAuth 2.0 and OpenID Connect
💡 First Principle: OAuth 2.0 answers "how does an app get permission to call an API on someone's behalf without holding their password?" — it's an authorization protocol. OpenID Connect (OIDC) adds a thin identity layer on top: "and how does the app learn who signed in?" Together they are modern authentication, and the Microsoft identity platform speaks both natively.
The division of labor shows up in the tokens. OAuth flows produce an access token — presented to a resource API (like Microsoft Graph) as a bearer credential scoped to specific permissions. OIDC adds the ID token — consumed by the app itself to establish the user's session and display "signed in as Alice." A refresh token accompanies them, letting the app obtain new access tokens silently when old ones expire — which, importantly, is the moment Entra can re-evaluate policy.
The canonical web sign-in is the authorization code flow:
Note where the password went: only ever to Entra (step 4). The app never sees it — it holds only tokens with the scopes the user or an admin consented to. That's why OAuth pairs naturally with least privilege, and why Phase 4 spends a whole subsection on consent: granting scopes is the authorization decision.
⚠️ Exam Trap: Access tokens are for resources; ID tokens are for the client app. A question about "the token an application validates to sign the user in" wants the ID token; "the token presented to Microsoft Graph" wants the access token. Swapping them is the classic distractor.
Reflection Question: Step 3 is the only place MFA and Conditional Access run in this diagram. What does that imply about when a policy change you make actually takes effect for a user who is already signed in?