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 and OpenID Connect (OIDC). These two are often used together, but they do different things: OAuth 2.0 is for authorization, and OIDC is for authentication. In this article, we’ll explain what each one does, go over the key terms, and show you how to use them in a real project.

What is OAuth?

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 — without ever seeing or storing your Google login credentials.

Authentication vs Authorization

In the context of OAuth and API security, the Client typically refers to an application (App) that requests access to a resource on behalf of a user.

Authentication 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?" The server validates the client’s 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.

On the other hand, Authorization 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.

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.

OAuth 2.0 Key Terminology and workflow

Term	Description
Resource Owner	The user who owns the data.
Client	The application requesting access (your app).
Resource Server	Server hosting user data (e.g., Google APIs).
Authorization Server	Server issuing tokens (e.g., Google OAuth server).
Access Token	Token that the client uses to access protected resources.
Refresh Token	Token to obtain a new access token without user involvement.

What is OpenID Connect (OIDC)?

OIDC is an authentication layer built on top of OAuth 2.0.
It allows clients to verify the identity of users and obtain basic profile information.

Key difference:

OAuth = authorization (OAuth 2.0 handles authorization—"Can" I access this?)

OIDC = authentication + authorization (OpenID Connect handles authentication—"Who" is this?)

OIDC introduces a new token type: the ID Token.

The Problem: OAuth and the Need for OpenID Connect (OIDC)

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

From a client’s 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 — managing permissions and granting scoped access to protected resources — not for authentication or sharing user identity data.

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

This misuse highlighted the need for a formal, consistent method to retrieve user identity data securely and reliably. OpenID Connect (OIDC) 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.

Example: Implementing Google Login (OAuth 2.0 + OpenID Connect)

Here’s a simple example using Laravel (PHP Framework). Please reference this link for a step-by-step guideline. https://laravel-news.com/connecting-laravel-socialite-with-google-client-php-library

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

In LTI 1.3 and LTI Advantage, the core specification relies on OAuth 2.0 and OpenID Connect (OIDC) to provide secure and standardized authentication and authorization between

• Platform (LMS) - like Moodle, Canvas, Blackboard (acts as the OpenID Provider)
• Tool (your client App) - like an assessment tool, analytics platform, etc. (acts as the Relying Party)

OAuth and OpenID Connect serve different but complementary purposes.
OAuth is for authorization — granting apps access to resources without exposing user credentials.
OpenID Connect (OIDC) is for authentication, verifying who the user is using a standard and secure method.