By Alain Ngeukeu4 min read795 words

Real Life Use Case : Codex Website Authentification using OAuth 2.0

Table of Contents

  1. Introduction
  2. Authentication
  3. Authorization
  4. OAuth 2.0 in Practice: The Codex Use Case
  5. Conclusion

1. Introduction

While building the onboarding feature for Codex, I came across two foundational concepts in web security: authentication and authorization. The reason these came up is that I wanted to allow users to create accounts so they could store and update their information at will. This strengthens networking within the community and brings more value to the platform.

To understand the underlying protocol powering this system, you can read my article on OAuth 2.0 here: https://www.alainngongang.dev/posts/understanding-oauth-2-0-why-every-developer-should-know-this-protocol

You can also explore the feature itself here: Codex v3.0.

One key design decision I made early on was that authentication always comes before authorization. A user must first prove who they are before the system can determine what they are allowed to do. The two concepts are closely related but serve distinct purposes, and understanding that distinction is what this article is about.


2. Authentication

Authentication answers one question: Who are you?

In the context of Codex, this means determining whether you are a registered member of the community or not. Before the system can do anything on your behalf, it needs to confirm your identity. Only after that confirmation can it decide what you are permitted to access.

This step is handled entirely by Supabase Auth, which delegates identity verification to trusted third-party services such as Google, GitHub, and LinkedIn. By doing this, Codex never handles your password directly. Instead, it receives a secure token from the identity provider confirming who you are.

This approach also reduces friction on the user side. In a world where most online platforms ask you to create yet another account with yet another email and password, allowing users to sign in with an existing identity they already trust makes the experience significantly smoother.


3. Authorization

Authorization answers a different question: Are you allowed to do this?

Once the system knows who you are, it checks what rights you have. This covers ownership, roles, and permissions. At the current stage of Codex, there is a single role: member, which comes with a defined set of rights.

In the future, new roles will be introduced, each with their own rules and permissions. The authorization layer is designed with this growth in mind, so expanding it will not require restructuring the system from scratch.


4. OAuth 2.0 in Practice: The Codex Use Case

image.png

The objective for this project was to build an onboarding flow paired with a dashboard. The authentication layer was implemented using Supabase Auth, which provides out-of-the-box support for OAuth 2.0. This allows Codex to delegate authentication to third-party providers like Google, GitHub, and LinkedIn, rather than managing credentials internally.

This is the core idea behind OAuth 2.0:

The application (Codex) never sees your password. Instead, the identity provider verifies your credentials, and if successful, issues a secure token that Codex uses to identify you and act on your behalf within the permissions you approved.

The flow works as follows.

  • When a user clicks "Sign in with Google," Codex redirects them to Google's login page.
  • The user authenticates directly with Google. Google then presents a consent screen asking the user to approve what Codex is allowed to access.
  • Once approved, Google issues a token back to Codex. From that point on, Codex uses that token to identify the user and grant them access to the platform.
  • At no point does Codex store or see the user's Google password. If access needs to be revoked, the user can do so directly from their Google account settings.

5. Conclusion

Authentication and authorization are two distinct but deeply connected pillars of a secure web application. Authentication establishes identity. Authorization defines what that identity is permitted to do. By implementing OAuth 2.0 through Supabase Auth, Codex offloads the most sensitive part of the process to trusted providers, reduces friction for users, and builds a solid foundation for a permission system that can grow over time.

If you want to dive deeper into how OAuth 2.0 works under the hood, check out my dedicated article on the topic: https://www.alainngongang.dev/posts/understanding-oauth-2-0-why-every-developer-should-know-this-protocol.

Thanks for reading.

Alain Ngongang