Introduction

OAuth 2.0 is one of the most widely used authorization frameworks on the internet. It allows applications to access user data from another service without sharing passwords.

For example:

Login with Google
Login with Facebook
Connect an app to your GitHub account
Allow a calendar app to access your Google Calendar

Instead of giving your password to every application, OAuth 2.0 provides a secure way to grant limited access using access tokens.

1. What is OAuth 2.0?

OAuth 2.0 (Open Authorization) is a protocol that allows a user to grant permission to an application to access resources from another application.

Simple example:

Imagine you use a calendar application:


User
 |
 | "Allow this app to access my Google Calendar"
 |
 ▼
Calendar Application
 |
 | Request permission
 |
 ▼
Google Authorization Server
 |
 | Gives Access Token
 |
 ▼
Calendar Application
 |
 | Uses Token
 |
 ▼
Google Calendar API

The calendar app never sees your Google password.

2. Why Do We Need OAuth 2.0?

Before OAuth, applications often required users to share usernames and passwords.

Example:


Your Password
      |
      ▼
Third-party Application
      |
      ▼
Access Your Account

Problems:

Passwords can be stolen
Users must trust every application
No permission control
Difficult to revoke access

OAuth 2.0 solves these problems:

✅ No password sharing
✅ Limited access permissions
✅ Access can be revoked anytime
✅ Secure token-based authentication

3. OAuth 2.0 Main Components

OAuth 2.0 has four important roles:

1. Resource Owner

The user who owns the data.

Example:


John's Google Account

2. Client Application

The application requesting access.

Examples:

Mobile app
Website
Backend service

Example:


Meeting Management System

3. Authorization Server

The server responsible for authentication and issuing tokens.

Examples:

Google OAuth Server
Facebook Login
GitHub OAuth

Responsibilities:

Login user
Ask for permission
Generate access token

4. Resource Server

The server that stores protected data.

Examples:

Google Calendar API
GitHub API
Facebook Graph API

4. OAuth 2.0 Flow Overview

The general flow looks like this:


+-------------+
|    User     |
+-------------+
       |
       | Login & Approve
       |
       ▼
+----------------------+
| Authorization Server|
|       Google         |
+----------------------+
       |
       | Access Token
       |
       ▼
+----------------+
| Client App     |
+----------------+
       |
       | API Request + Token
       |
       ▼
+----------------+
| Resource API   |
| Google Calendar|
+----------------+

5. OAuth 2.0 Authorization Code Flow

The Authorization Code Flow is the most common OAuth 2.0 flow.

Step 1: User Clicks Login

Example:


Login with Google

Your application redirects the user:


https://accounts.google.com/o/oauth2/auth

with parameters:


client_id
redirect_uri
response_type=code
scope=email profile

Example:


Application
      |
      |
      ▼
Google Login Page

Step 2: User Gives Permission

Google shows:


Application wants access to:

✓ View your profile
✓ Read your email

Allow?

User clicks:


Allow

Step 3: Authorization Server Returns Code

Google redirects back:


https://myapp.com/callback?code=abc123

The application receives:


Authorization Code

Example:


code=4/0AX4XfWh8xxxxx

This code is temporary.

Step 4: Exchange Code for Access Token

The backend sends:


Authorization Code
        |
        ▼
Google Token Endpoint

Request:


POST https://oauth2.googleapis.com/token

Data:


client_id
client_secret
code
grant_type=authorization_code
redirect_uri

Response:


{
 "access_token": "ya29.a0AfH6",
 "expires_in": 3600,
 "refresh_token": "1//09xxxxx"
}

Step 5: Access Protected Resources

Now the application uses the access token:

Request:


GET /calendar/events
Authorization: Bearer ACCESS_TOKEN

Example:


Authorization: Bearer ya29.a0AfH6

Google checks the token.

If valid:


Return Calendar Data

6. Access Token vs Refresh Token

Access Token

Used to call APIs.

Example:


Access Token
     |
     ▼
Google Calendar API

Usually expires:


1 hour

Refresh Token

Used to get a new access token.

Example:


Refresh Token
       |
       ▼
New Access Token

Refresh tokens usually last longer.

7. OAuth 2.0 Grant Types

OAuth 2.0 provides different flows.

1. Authorization Code Flow

Most common.

Used for:

Web applications
Mobile apps

Example:


Laravel Website
        |
        ▼
Google OAuth

2. Client Credentials Flow

Used for server-to-server communication.

Example:


Backend Service
       |
       ▼
API Server

No user involved.

3. Device Authorization Flow

Used for devices without browsers.

Examples:

Smart TV
Console

Flow:


TV Screen
   |
Show Code
   |
User Opens Browser

4. Password Grant (Deprecated)

Old method:


Username
Password
     |
     ▼
Access Token

Not recommended today.

8. OAuth 2.0 Example: Login with Google

Real-world example:


User
 |
 | Click "Login Google"
 |
 ▼
Your Website
 |
 | Redirect
 |
 ▼
Google OAuth
 |
 | User approves
 |
 ▼
Authorization Code
 |
 ▼
Your Backend
 |
 | Exchange Code
 |
 ▼
Access Token
 |
 ▼
Google API

9. OAuth 2.0 Security Best Practices

Store Client Secret Safely

Never expose:


client_secret

in frontend code.

Bad:


const secret = "123456";

Good:


Backend Environment Variable

Example:


.env

GOOGLE_CLIENT_SECRET=xxxxx

Use HTTPS

OAuth requires secure communication.

Use:


https://example.com

Not:


http://example.com

Limit Permissions Using Scopes

Instead of:


Access everything

Request only:


calendar.readonly
email
profile

Store Tokens Securely

Avoid:


Local Storage

Better:


Encrypted Database
Secure Cookies

10. OAuth 2.0 in Laravel Example

Install Google Client:


composer require google/apiclient

Create credentials in Google Cloud:


Google Cloud Console
        |
        ▼
OAuth Consent Screen
        |
        ▼
Create OAuth Client ID

Environment:


GOOGLE_CLIENT_ID=xxxx
GOOGLE_CLIENT_SECRET=xxxx
GOOGLE_REDIRECT_URI=https://example.com/auth/google/callback

Redirect user:


$client = new Google\Client();

$client->setClientId(
    env('GOOGLE_CLIENT_ID')
);

$client->setClientSecret(
    env('GOOGLE_CLIENT_SECRET')
);

$client->setRedirectUri(
    env('GOOGLE_REDIRECT_URI')
);

$url = $client->createAuthUrl();

11. OAuth 2.0 vs API Key

Feature	OAuth 2.0	API Key
User Login	Yes	No
Permission Control	Yes	Limited
User Data Access	Yes	No
Security	Higher	Lower
Example	Google Login	Weather API

12. Common OAuth 2.0 Errors

Invalid Client

Cause:


Wrong Client ID or Secret

Fix:

Check:


GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET

Redirect URI Mismatch

Cause:

Your callback URL does not match.

Example:

Google:


https://app.com/callback

Your app:


https://app.com/auth/callback

Fix:

Make them identical.

Invalid Scope

Cause:

Requested permission does not exist.

Fix:

Check OAuth scopes.

Conclusion

OAuth 2.0 provides a secure way for applications to access user resources without sharing passwords.

The main idea:


User Login
     |
Permission
     |
Authorization Code
     |
Access Token
     |
API Access

Souy Soeng

OAuth 2.0 Explained for Beginners

Introduction

1. What is OAuth 2.0?

2. Why Do We Need OAuth 2.0?

3. OAuth 2.0 Main Components

1. Resource Owner

2. Client Application

3. Authorization Server

4. Resource Server

4. OAuth 2.0 Flow Overview

5. OAuth 2.0 Authorization Code Flow

Step 1: User Clicks Login

Step 2: User Gives Permission

Step 3: Authorization Server Returns Code

Step 4: Exchange Code for Access Token

Step 5: Access Protected Resources

6. Access Token vs Refresh Token

Access Token

Refresh Token

7. OAuth 2.0 Grant Types

1. Authorization Code Flow

2. Client Credentials Flow

3. Device Authorization Flow

4. Password Grant (Deprecated)

8. OAuth 2.0 Example: Login with Google

9. OAuth 2.0 Security Best Practices

Store Client Secret Safely

Use HTTPS

Limit Permissions Using Scopes

Store Tokens Securely

10. OAuth 2.0 in Laravel Example

11. OAuth 2.0 vs API Key

12. Common OAuth 2.0 Errors

Invalid Client

Redirect URI Mismatch

Invalid Scope

Conclusion

Post a Comment

Souy Soeng