Despite eight years of web development experience, I recently encountered a humbling moment that many developers can relate to. While implementing Supabase authentication in a Next.js application, I found myself stumbling over terms like PKCE, code challenge, consent screen, and back channel. Despite having integrated numerous third-party authorizations with Google, GitHub, and Twitter, I had never deeply understood the underlying OAuth mechanisms.
OAuth was designed to be a secure authorization protocol for allowing third-party applications to access resources on behalf of users. Over the years, it became the standard for delegated authorization. For example, imagine you are building a photo editing app and you want to save the users' work directly to their Google Drive.
Giving access to your Google Drive to your photo editing app is not as simple as it sounds. Let's see how these integrations worked before OAuth became the norm.
A Historical Perspective: Authorization Before OAuth
Imagine you own a house (your account). If you wanted a cleaning service (third-party app) to tidy up while you're at work, you'd have to give them your actual house key. They could access everything, not just the areas they needed to clean. They'd keep a copy of your key at their office.
This is exactly what happened before OAuth was introduced. Users had to provide their actual login credentials (username and password) to any third-party application that needed access to their data. These applications would store these credentials in their databases and use them to directly access the service's APIs. It's like giving your email password to a third-party app that needs to read your emails. The app would store your password and use it whenever it needed to access your emails. This meant applications had unlimited access to user accounts with no way to restrict what they could do or for how long they could do it.
See the screenshot below. In the vintage days, yelp used to ask for your email credentials to find freinds. Risky much !
OAuth 1.0: The First Security Guard
Real-World Analogy: Like introducing a security company managing access to your house. Instead of your house key, the cleaning service gets a temporary pass from the security company, limited to specific areas and times.
OAuth 1.0 introduced a token-based authorization system. When an application needed access to your data, it would first request permission from the service provider (like Google). The provider would generate access tokens and access token secrets that the application could use instead of your password. These tokens had defined scopes that limited what they could access. However, the process required complex cryptographic signatures for each request, making it challenging for developers to implement correctly and difficult to use with mobile applications.
OAuth 2.0: The Modern Concierge Service
Real-World Analogy: Like a smart building system where different visitors get different types of digital passes - cleaning service gets limited access, property manager gets broader access, but nobody gets the master key.
OAuth 2.0 emerged as a complete authorization framework, offering more flexibility and simpler implementation. It introduced different "grant types" for various use cases. When an app needs access to your Google data, it redirects you to Google's authorization server. After you log in, Google presents a consent screen showing exactly what permissions the app is requesting (like "read your contacts" or "send emails on your behalf"). If you approve, Google issues an access token to the app that only works for those specific permissions. The app never sees your password, and you can revoke its access at any time through Google's security settings. The access token expires after a set time, but the app can obtain a new one using a "refresh token" without requiring you to log in again.
I'm currently exploring more advanced concepts like PKCE, which adds an extra layer of security for mobile and single-page applications. I will keep writing about these concepts as I learn them.
P.S. If you're a security expert reading this and spot any misconceptions, please reach out. We're all here to learn! 😄