3.1.4.2. Implement OAuth2.0 and OpenID Connect

First Principle: "OAuth 2.0" is an authorization framework that enables applications (clients) to obtain limited access to a user's protected resources on an HTTP service. "OpenID Connect (OIDC)" is an identity layer built on "OAuth 2.0", focused on authenticating users and providing basic profile information.

What It Is: "OAuth 2.0" and "OpenID Connect (OIDC)" are industry-standard protocols for authentication and authorization, widely used by the Microsoft Identity Platform.

Visual: "OAuth 2.0 Authorization Code Flow with OIDC"

Loading diagram...

Key Roles in OAuth 2.0:

• "Resource Owner": The user who owns the data or resources.
• "Client": The application requesting access on behalf of the user.
• "Authorization Server": Issues access tokens after authenticating the user and obtaining consent (e.g., "Entra ID").
• "Resource Server": Hosts the protected resources and validates access tokens (e.g., "Microsoft Graph", your custom API).

"Authorization Code Grant Flow": The most common and secure "OAuth 2.0 flow" for web applications and native clients.

1. The user is redirected to the Authorization Server (e.g., "Entra ID") to sign in and grant consent.
2. The Authorization Server returns an authorization code to the client application.
3. The client (server-side) exchanges this code for an access token (and optionally an ID token) with the Authorization Server.
4. The access token is then used by the client to access protected resources from the Resource Server. This flow keeps user credentials away from the client and supports secure, server-side token handling.

"OpenID Connect (OIDC)": An identity layer built on top of "OAuth 2.0".

• "Focus": "OIDC" is focused on authentication—verifying who the user is.
• "ID Token": It provides an ID Token (a "JWT - JSON Web Token") that allows clients to confirm the user's identity and obtain basic profile information (claims).

"Entra ID" Role: "Entra ID" acts as both an "OAuth 2.0 Authorization Server" and an "OpenID Connect provider". It issues access tokens for "resource access" and ID tokens for authentication, enabling secure, standards-based sign-in and delegated access for Azure and Microsoft 365 services.

Scenario: You are building a new web application that needs to securely sign in users using their Entra ID accounts and then access a protected backend API on behalf of the signed-in user. You need to ensure the user's identity is verified and the application is authorized to call the API.

Reflection Question: How do "OAuth 2.0 (for authorization)" and "OpenID Connect (for authentication)", when integrated with "Entra ID", fundamentally enable secure, standards-based user sign-in and delegated access to protected resources for modern cloud applications?

💡 Tip: Remember the core difference: "OAuth 2.0 = Authorization (access to resources)"; "OpenID Connect = Authentication (user identity verification)". OIDC sits on top of OAuth 2.0.