{"id":721,"date":"2025-04-11T16:15:18","date_gmt":"2025-04-11T08:15:18","guid":{"rendered":"https:\/\/witlab.ph\/blog\/?p=721"},"modified":"2025-04-19T18:55:35","modified_gmt":"2025-04-19T10:55:35","slug":"understanding-oauth-2-0-and-openid-connect-oidc","status":"publish","type":"post","link":"https:\/\/witlab.ph\/blog\/understanding-oauth-2-0-and-openid-connect-oidc\/","title":{"rendered":"Understanding OAuth 2.0 and OpenID Connect (OIDC)"},"content":{"rendered":"\n

Authentication and authorization are important parts of building modern web and mobile apps. To handle them safely and efficiently, developers use two popular protocols: OAuth 2.0<\/strong> and OpenID Connect (OIDC)<\/strong>. These two are often used together, but they do different things: OAuth 2.0 is for authorization<\/strong>, and OIDC is for authentication<\/strong>. In this article, we\u2019ll explain what each one does, go over the key terms, and show you how to use them in a real project.<\/p>\n\n\n\n

<\/p>\n\n\n\n

What is OAuth?<\/strong><\/p>\n\n\n\n

OAuth is an authorization framework that enables a client application (often a third-party app) to access resources from another system securely by using an access token, which is valid for a limited time. Instead of sharing login credentials, users authorize the client app to act on their behalf. For example, when you log in to shop.witlab.ph (a third-party app) using your Google account, OAuth facilitates delegated authorization. This means WITLAB can access certain Google account information with your permission \u2014 without ever seeing or storing your Google login credentials.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Authentication vs Authorization<\/strong><\/p>\n\n\n\n

In the context of OAuth and API security, the Client<\/strong> typically refers to an application (App) that requests access to a resource on behalf of a user.<\/p>\n\n\n\n

Authentication<\/strong> is the process of verifying the identity of the client (App). When a connection is established between a client and a server, authentication answers the question, “Who is the client?”<\/em> The server validates the client\u2019s credentials, which may be passed in various forms within the HTTP request (such as headers or request parameters). If authentication fails, the server responds with an HTTP 401 (Unauthorized) status code.<\/p>\n\n\n\n

On the other hand, Authorization<\/strong> determines whether the authenticated client (App) has permission to perform a specific action or access a particular resource. During authorization, the server typically verifies the client’s access rights by decoding a token (such as a Bearer Token) included in the HTTP request. If the client is not authorized to access the requested resource, the server returns an HTTP 403 (Forbidden) response.<\/p>\n\n\n\n

It is not always necessary to perform an explicit authentication check before authorization. In many REST API designs, verifying the authorization token alone is sufficient, as the token itself contains proof of both authentication and authorization.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

OAuth 2.0 Key Terminology<\/strong> and workflow<\/strong><\/p>\n\n\n\n

Term<\/strong><\/td>Description<\/strong><\/td><\/tr>
Resource Owner<\/td>The user who owns the data.<\/td><\/tr>
Client<\/td>The application requesting access (your app).<\/td><\/tr>
Resource Server<\/td>Server hosting user data (e.g., Google APIs).<\/td><\/tr>
Authorization Server<\/td>Server issuing tokens (e.g., Google OAuth server).<\/td><\/tr>
Access Token<\/td>Token that the client uses to access protected resources.<\/td><\/tr>
Refresh Token<\/td>Token to obtain a new access token without user involvement.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

What is OpenID Connect (OIDC)?<\/strong><\/p>\n\n\n\n

OIDC<\/strong> is an authentication layer<\/strong> built on top of OAuth 2.0.
It allows clients to verify the identity of users and obtain basic profile information.<\/p>\n\n\n\n

Key difference:<\/strong><\/p>\n\n\n\n

OAuth = authorization (OAuth 2.0<\/strong> handles authorization\u2014”Can” I access this?)<\/p>\n\n\n\n

OIDC = authentication + authorization (OpenID Connect<\/strong> handles authentication\u2014”Who” is this?)<\/p>\n\n\n\n

OIDC introduces a new token type: the ID Token<\/strong>.<\/p>\n\n\n\n

<\/p>\n\n\n\n

The Problem: OAuth and the Need for OpenID Connect (OIDC)<\/strong><\/p>\n\n\n\n

When “Login with Facebook” or “Login with Google” features were first introduced around 2014, OAuth began to be widely used not just for authorization<\/strong>, but also for authentication<\/strong>. In these scenarios, after the client (App) obtained an access token from the authorization server, it often needed some basic user information \u2014 such as name, email address, or profile picture \u2014 to personalize the user experience.<\/p>\n\n\n\n

From a client\u2019s perspective, this was a reasonable request. After all, the authorization server already had this user information available. However, OAuth was originally designed only for authorization<\/strong> \u2014 managing permissions and granting scoped access to protected resources \u2014 not for authentication or sharing user identity data.<\/p>\n\n\n\n

Using OAuth alone for authentication led to a significant problem: there was no standardized way<\/strong> to deliver user information to the client. Different providers implemented their own custom solutions, leading to inconsistencies and a fragmented ecosystem.<\/p>\n\n\n\n

This misuse highlighted the need for a formal, consistent method to retrieve user identity data securely and reliably. OpenID Connect (OIDC)<\/strong> was introduced to solve this problem. OIDC builds on top of OAuth 2.0 and adds a standardized identity layer, allowing clients to obtain verified user information (such as user ID, name, email, etc.) via a well-defined and secure protocol after the authorization process.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Example: Implementing Google Login (OAuth 2.0 + OpenID Connect)<\/strong><\/p>\n\n\n\n

Here\u2019s a simple example using Laravel <\/strong>(PHP Framework). Please reference this link for a step-by-step guideline. https:\/\/laravel-news.com\/connecting-laravel-socialite-with-google-client-php-library<\/a><\/p>\n\n\n\n

Also, this scenario is used in our LTI solution. You can understand it with the following link. https:\/\/witlab.ph\/blog\/what-is-lti-a-simple-guide-to-understanding-educational-dx-for-non-techies<\/a><\/p>\n\n\n\n

In LTI 1.3 and LTI Advantage<\/strong>, the core specification relies on OAuth 2.0<\/strong> and OpenID Connect (OIDC)<\/strong> to provide secure and standardized authentication and authorization between<\/p>\n\n\n\n