RFC 6749 Deep Dive: Understanding OAuth 2.0 Design Decisions from the Specification

Introduction Everyone has heard of OAuth 2.0. If you have ever clicked a "Sign in with Google" button, you are already benefiting from it. But what if someone asked you these questions? "Explain the difference between Authorization Code Grant and Implicit Grant from a security perspective." "Why should Client Credentials Grant not issue a Refresh Token?" "What exactly does PKCE protect against?" Surprisingly few people can answer these fluently. Getting by with "it just works somehow" is a recipe for authorization bugs and vulnerabilities down the road. This article dissects RFC 6749 (The OAuth 2.0 Authorization Framework) based on the original specification, building a fundamental understanding of OAuth 2.0's design philosophy. By the time you finish reading, the "why" behind each design decision should click into place. 1. The Problem OAuth 2.0 Solved Before OAuth 2.0, the only way for a third-party application to access a user's resources was to hand over the user's password directl