Authorization
Introduction to OAuth 2.0 and Core Concepts
Hello there! As a developer exploring authentication and authorization systems, you'll inevitably encounter OAuth 2.0. It's a crucial concept, but one that often leads to confusion. This article provides an overview, helping you grasp the core nature of OAuth 2.0 and its fundamental concepts before we delve into the specific grant types.
What is OAuth 2.0? Authorization or Authentication?
Many often mistake OAuth 2.0 for an authentication protocol. However, it's crucial to remember:
OAuth 2.0 is an authorization framework that enables a client application to obtain limited access to a user's protected resources on a resource server, without needing to know the user's credentials (username and password).
Example
You use an online photo editing app (the Client Application) and want it to access your photos stored on Google Photos (the Resource Server). Instead of sharing your Google password, you grant it specific, limited permissionβjust to view and edit your photos. OAuth 2.0 provides this secure mechanism.
A Clear Distinction: Authorization vs. Authentication
This is a pivotal point for truly understanding OAuth 2.0:
Authentication: Answers the question, "Who are you?"
This is the process of proving your identity. For example, when you log into Google using your email and password, the Google system authenticates that you are indeed that person.
Authorization: Answers the question, "What can you (or this application on your behalf) do?"
This is the process of determining access rights to resources. After you log into Google, a third-party photo editing app wants to access your photo albums. OAuth 2.0 helps you authorize that app to only view and edit specific photos, without sharing your Google password.
Real-world Example
You log into Google Photos (Authentication step - Google verifies your identity)
A photo editing app requests permission to "View and manage your photos" (Authorization step via OAuth 2.0)
The app receives an access_token (permission slip) to access your photos without knowing your password
Key Point: OAuth 2.0 focuses on granting permissions (authorization), not verifying identity (authentication).
Why Do We Need OAuth 2.0?
Before OAuth, applications often required users to directly provide their usernames and passwords to access data on other services. This approach had significant drawbacks:
- High security risk: The client application could store, misuse, or expose the user's credentials.
- No scope limitation: The client application had full access, just like the user, potentially viewing, editing, or deleting any data. This violates the "Principle of Least Privilege".
- Difficult to revoke access: If you wanted to revoke an app's access, you'd have to change your password, which affected all other applications using that password.
OAuth 2.0 addresses these issues by providing a secure and flexible mechanism for authorizing access without sharing credentials.
Key Roles in OAuth 2.0
To better understand OAuth 2.0, we need to familiarize ourselves with the main roles involved in the flow:
- Resource Owner: The end-user who owns the protected data or resources (e.g., you, as the owner of photos on Google Photos).
- Client (Application): The application that wants to access the Resource Owner's protected resources (e.g., a photo editing app). The Client must be pre-registered with the Authorization Server to obtain a client_id and potentially a client_secret.
- Authorization Server: This server is responsible for authenticating the Resource Owner and issuing an authorization code or access token to the Client after the Resource Owner's consent. This is often part of an Identity Provider (IdP) like Google, Facebook, or Microsoft Azure AD.
- Resource Server: This server hosts the protected resources and is capable of accepting access requests authenticated with an access_token. Resource Servers are typically APIs (e.g., the Facebook Graph API, Google Drive API, Twitter API).
The relationships between these roles can be summarized as:
(User)"] B["π± Client App
(Photo Editor)"] C["π Authorization Server
(Google)"] D["ποΈ Resource Server
(Google Photos API)"] A -->|"1. Grant Permission"| B B -->|"2. Request Authorization"| C C -->|"3. Authenticate User"| A C -->|"4. Issue Access Token"| B B -->|"5. Access Resources"| D D -->|"6. Return Protected Data"| B
Detailed OAuth 2.0 Flow
Grant Permission
User clicks "Connect to Google Photos" and decides to authorize the photo editing app
Request Authorization
App redirects browser to Google's /authorize endpoint with client_id, redirect_uri, and scope parameters
Authenticate User
Google shows login screen, user enters credentials, and consent screen displays requested permissions
Issue Access Token
Google redirects back with authorization_code, then app exchanges it for access_token via /token endpoint
Access Resources
App uses the access_token in Authorization header to make API calls to Google Photos
Return Protected Data
Google Photos API validates the token and returns the user's photos that the app can now display and edit
Flow Summary:
- The Resource Owner allows the Client to access their resources
- The Client interacts with the Authorization Server to obtain permission
- The Authorization Server grants an Access Token to the Client
- The Client uses the Access Token to access resources on the Resource Server