OAuth 2.0 Introduction — Authorization Framework for Delegated Access
In this tutorial, you will learn about OAuth 2.0 Introduction. We cover key concepts, practical examples, and best practices to help you master this topic.
OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to user resources without exposing user credentials.
What You'll Learn
The core OAuth2 concepts: roles, grant types, tokens, scopes, and how OAuth2 differs from simple authentication.
Why It Matters
Sharing passwords with third-party apps is dangerous. OAuth2 solves this by issuing scoped, revocable tokens. When you click "Sign in with Google," you are using OAuth2 to grant limited access without sharing your password.
Real-World Use
"Login with Google," GitHub OAuth, Facebook Login, Slack integrations — all use OAuth2. Doda Browser uses OAuth2 so users can grant access to Google Drive without sharing their Google password.
flowchart LR
A["Resource Owner\n(User)"] -->|"Authorizes"| B["Client App"]
B -->|"Request Token"| C["Authorization Server"]
C -->|"Access Token"| B
B -->|"API Call + Token"| D["Resource Server"]
D -->|"Protected Data"| B
style A fill:#dbeafe,stroke:#2563eb
style B fill:#fef3c7,stroke:#d97706
style C fill:#fef3c7,stroke:#d97706
style D fill:#dcfce7,stroke:#16a34a
The Four Roles
| Role | Description | Example |
|---|---|---|
| Resource Owner | The user who owns the data | You |
| Client | The app requesting access | Doda Browser |
| Authorization Server | Issues tokens after auth | Google Accounts |
| Resource Server | Hosts the protected data | Google Drive API |
Grant Types Overview
| Grant | Client Type | Best for |
|---|---|---|
| Authorization Code | Confidential | Web apps with backend |
| Implicit (deprecated) | Public | Legacy SPAs |
| Client Credentials | Confidential | Machine-to-machine |
| ROPC | Trusted | First-party apps (avoid) |
| PKCE Extension | Public | Mobile apps, SPAs |
Common Mistakes
1. Using OAuth2 for Authentication
OAuth2 is authorization, not authentication. It does not tell you who the user is — only what they can access. Use Openid Connect for authentication.
2. Not Using State Parameter
Without state, CSRF Attacks can swap authorization codes. Always use a unique, unguessable state.
3. Exposing Client Secrets in Public Clients
Mobile apps and SPAs cannot keep secrets. Use PKCE instead.
4. Confusing Access Tokens with API Keys
Access tokens are short-lived, scoped, and revocable. API keys are static and identify the app, not the user.
5. Storing Tokens Insecurely
Access tokens grant API access. Store them in httpOnly cookies (web) or secure device storage (mobile).
Practice Questions
- What are the four roles in OAuth2?
- What is a grant type?
- Why was the Implicit grant deprecated?
- What is the difference between OAuth2 and OpenID Connect?
- What does the state parameter protect against?
Answers:
- Resource Owner, Client, Authorization Server, Resource Server.
- A grant type is a method for obtaining an access token. Each grant is designed for a specific client type and use case.
- The Implicit grant exposed access tokens in the URL fragment. PKCE provides a more secure alternative.
- OAuth2 authorizes access (scopes, tokens). OpenID Connect adds authentication (ID token with user identity).
- The state parameter prevents CSRF attacks by correlating the authorization request with the callback.
Challenge: Map a real "Login with Google" flow. Identify each OAuth2 role and grant type. How does the flow differ between a web app and a mobile app?
FAQ
Mini Project
Create a Python script that generates an OAuth2 authorization URL, handles the redirect callback (simulated), exchanges the code for tokens, and makes an authenticated API call.
What's Next
Now learn about OAuth2 Roles in depth — the four participants in every OAuth2 flow.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro