OIDC 流程概览

In this lesson, we'll explore the main flows (or grant types) used in OpenID Connect (OIDC). These flows define how your application (the Client) interacts with an OpenID Provider (like Google or Auth0) to get identity information about a user.

OIDC builds directly on top of OAuth2, so these flows will look familiar if you've studied OAuth2 grant types.

Remember, OIDC is an identity layer built on OAuth2. This means it reuses OAuth2's authorization flows, but with a crucial addition: the ID Token.

• ID Token: A JSON Web Token (JWT) containing information (claims) about the authenticated user.
• The choice of flow determines how this ID Token (and an Access Token) is delivered to your client application.

This is the most secure and recommended flow for OIDC, especially for web applications with a backend (confidential clients).

• How it works: The client exchanges an authorization code for tokens (ID Token and Access Token) directly with the OpenID Provider's token endpoint.
• This exchange happens over a secure, server-to-server (back-channel) connection.

The Authorization Code Flow is preferred because the tokens are never exposed in the user's browser or URL.

• Security: Tokens are exchanged directly between servers, reducing the risk of interception.
• Client Type: Ideal for web applications with a backend.
• PKCE: Often paired with Proof Key for Code Exchange (PKCE) for public clients (like mobile apps) to prevent code interception.

The Implicit Flow delivers tokens directly to the client via the browser's URL fragment after user authentication. It was historically used for single-page applications (SPAs).

Important: Due to security concerns (like token leakage via browser history or referrer headers), the Implicit Flow is largely deprecated by the OAuth2.0 and OIDC specifications.

While simpler to implement for browser-based apps, its security drawbacks are significant:

• No Code Exchange: Tokens are granted directly, without a secure back-channel exchange.
• Front-Channel Exposure: Tokens appear in the browser's URL, making them vulnerable.
• No Refresh Tokens: Typically, this flow doesn't issue refresh tokens, requiring re-authentication.

Modern SPAs should use the Authorization Code Flow with PKCE instead.

The Hybrid Flow combines elements of both the Authorization Code and Implicit flows. It allows the client to receive some tokens via the front-channel (browser) and others via the back-channel (server-to-server).

• For example, an ID Token might be returned directly in the URL, while an Access Token is obtained via a code exchange.

This flow offers flexibility but comes with increased complexity and potential security trade-offs, depending on what tokens are delivered via the front-channel.

• Use Cases: Can be used when a client needs immediate access to an ID Token (e.g., for UI updates) but wants to fetch the Access Token more securely.
• Considerations: Carefully weigh the security implications of any tokens returned directly to the browser.

When selecting an OIDC flow for your application, always prioritize security:

• Web Apps (Confidential Clients): Use Authorization Code Flow with PKCE.
• Mobile/Desktop Apps (Public Clients): Use Authorization Code Flow with PKCE.
• SPAs (Public Clients): Use Authorization Code Flow with PKCE.
• Implicit Flow: Avoid using it for new applications due to security risks.
• Hybrid Flow: Use with caution and a clear understanding of its security implications.

Which of the following statements about OpenID Connect (OIDC) flows are TRUE?

You've now got an overview of the primary OIDC flows:

• Authorization Code Flow: The most secure, recommended for most applications, especially with PKCE.
• Implicit Flow: Largely deprecated due to security concerns.
• Hybrid Flow: A flexible but more complex option combining elements of both.

Understanding these flows is crucial for implementing secure identity solutions. Next, we'll dive deeper into implementing specific OIDC flows.