OAuth 2.0とOpenID Connect

Welcome! In this lesson, we'll dive into OAuth 2.0 and OpenID Connect, two crucial protocols for modern web security.

First, let's understand OAuth 2.0. It's an industry-standard protocol for authorization. Think of it as a way to grant an application limited access to a user's resources without giving away their password.

• Authorization: Granting permission to do something.
• Authentication: Verifying who someone is.

OAuth 2.0 is NOT for authentication by itself, but it's often confused!

OAuth 2.0 involves four key roles working together:

• Resource Owner: The user who owns the protected data (e.g., their photos on Google).
• Client: The application requesting access to the user's resources (e.g., a photo printing app).
• Authorization Server: The server that issues access tokens to the client after the resource owner's consent (e.g., Google's auth server).
• Resource Server: The server hosting the protected resources, capable of accepting access tokens (e.g., Google Photos API).

Understanding these roles is key to grasping the flow.

OAuth 2.0 defines several ways (called 'grant types') for a client to get an access token. The Authorization Code Flow is the most common and secure for web applications.

It's a multi-step process designed to keep sensitive credentials (like your password) away from the client application and directly between you and the Authorization Server.

Let's break down how this secure flow works step-by-step.

It all starts when the Client application needs to access a user's protected resources (like their calendar). The client redirects the Resource Owner's browser to the Authorization Server.

This redirect includes:

• The client's ID (client_id)
• The type of access requested (scope, e.g., read:calendar)
• Where to send the user back (redirect_uri)

The user is now interacting directly with the Authorization Server.

At the Authorization Server, the Resource Owner (you!) is prompted to log in (if not already) and then asked if they grant the Client application the requested permissions.

If permission is granted, the Authorization Server redirects the user's browser back to the Client's pre-registered redirect_uri. This redirect includes a temporary, single-use authorization code.

This code is short-lived and doesn't grant access by itself.

Now, the Client application has the authorization code. It then makes a direct, server-to-server request to the Authorization Server's token endpoint.

In this request, the client exchanges the authorization code for:

• An Access Token
• Optionally, a Refresh Token

This direct communication ensures the client's secret (if it has one) and the tokens are never exposed in the browser.

After the exchange, the Client holds two important tokens:

• Access Token: This is the actual credential used to access the Resource Server. It's usually short-lived (minutes to hours) and contains 'scopes' defining what the client can do.
• Refresh Token: This is a long-lived credential used by the client to obtain a new access token when the current one expires, without needing the user to re-authenticate. It must be stored securely by the client!

The client uses the Access Token to make requests to the Resource Server.

While OAuth 2.0 is great for authorization, it doesn't directly provide user authentication. That's where OpenID Connect (OIDC) comes in!

OIDC is an identity layer built on top of OAuth 2.0. It allows clients to verify the identity of the Resource Owner (the user) and get basic profile information.

Think of it as adding a 'who are you?' layer to the 'what can you do?' of OAuth.

The core of OIDC is the ID Token. This is a JSON Web Token (JWT) that contains claims about the authenticated user.

Common claims include:

• sub (subject): Unique identifier for the user.
• name: User's full name.
• email: User's email address.
• iss (issuer): The URL of the OIDC provider.
• aud (audience): The client ID for which the token is intended.

The client verifies the ID Token's signature to ensure its authenticity and integrity.

Great job! You've learned the fundamentals of OAuth 2.0 and OpenID Connect.

• OAuth 2.0 is an authorization framework, allowing delegated access to resources.
• It involves a Resource Owner, Client, Authorization Server, and Resource Server.
• The Authorization Code Flow is the most secure for web apps.
• OpenID Connect builds on OAuth 2.0 to provide an identity layer for user authentication.
• ID Tokens (JWTs) carry user identity claims, while Access Tokens grant resource access.

Understanding these protocols is vital for building secure and modern applications!