Table of Contents

A Quick Note

In the past three years, while working on web applications, I've often come across the need to let users log in with third-party services (e.g., Google, GitHub, Facebook). There are tons of tutorials out there, many taking different approaches. Some seem a lot easier, while others feel way more tedious. As the saying goes, “shortcuts often come with hidden costs." I’ve realized that many tutorials skip over the crucial parts of OAuth and only show the easy—but vulnerable—methods.

Today, I’m going to dive deeper into the theory behind OAuth: what it is, the different types of flows, and why they’re designed the way they are. Hope you find it helpful!

What is OAuth

OAuth (Open Authorization) is an open standard for authorization that allows users to securely sign in using a third-party service (e.g., Facebook, Google, Line) and grant your app permission to access their protected resources without sharing their credentials directly.

What I mean by "sharing their credentials directly":

Your app will never see the user’s Google (or other third-party) password during the authorization process. Instead, the third-party service handles authentication and provides your app with a token to access the user's data (we will discuss this in detail later in this post).

OAuth 2.0

You might have heard of OAuth 2.0 but rarely hear people mention OAuth 1.0. Simply put, OAuth 2.0 is a more modern and secure version. For simplicity, unless explicitly mentioned otherwise, the term “OAuth” will refer to OAuth 2.0.

Terminology

Here are some common terms you'll encounter in the context of OAuth:

• End-user: the person (user) using your application
• Client: The application requesting access to the end-user’s protected resources.
• Authorization server: A third-party server (e.g., Google) that authenticates the end-user and issues tokens to the client.

We’ll dive deeper into the role of each in the next section.

Types of Flows

In OAuth, there are three types of flows: