OAuth 2.0 Roles Explained

Overview

OAuth 2.0 is a standard protocol that lets third‑party applications obtain limited access to a user’s resources without handling passwords. The protocol defines four key roles that each play a distinct part in the flow. Understanding these roles helps junior developers design secure integrations and avoid common pitfalls such as exposing access tokens or misusing client secrets.

The Four Roles

Resource Owner

The resource owner is the person (or organization) who owns the protected data. In everyday terms, this is the user who wants to let an app access part of their account.

Real‑world example: A user wants to let a photo‑editing website automatically upload pictures from their Google Photos account. The user is the resource owner; they grant the website permission to read and write photos.

Key points: - Holds the ultimate authority over the data. - Interacts directly with the client (e.g., clicks “Allow” on a consent screen). - Never shares their credentials with the client.

Client

The client is the application that requests access to the protected resources. It can be a web app, mobile app, or server‑side service.

Real‑world example: A fitness tracking mobile app needs to read a user’s step count from a wearable device’s API. The mobile app is the client; it initiates the OAuth flow to obtain a token that authorizes the request.

Key points: - Identifies itself to the authorization server (client ID, sometimes client secret). - Never sees the resource owner’s password. - Receives an access token (and optionally a refresh token) from the authorization server.

Authorization Server

The authorization server is responsible for authenticating the resource owner and issuing access tokens. It validates the request, obtains consent, and returns tokens to the client.

Real‑world example: When the fitness app redirects the user to Google’s sign‑in page, Google acts as the authorization server. After the user logs in and consents, Google issues an access token that the app can use to call the wearable API.

Key points: - Verifies the resource owner’s identity (often via login or social provider). - Issues short‑lived access tokens and optional refresh tokens. - Handles token revocation and expiration.

Minimal Python illustration (token endpoint)

import requests

def exchange_code_for_token(client_id, client_secret, code, redirect_uri):
    token_url = "https://auth.example.com/oauth/token"
    payload = {
        "grant_type": "authorization_code",
        "code": code,
        "redirect_uri": redirect_uri,
        "client_id": client_id,
        "client_secret": client_secret,
    }
    response = requests.post(token_url, data=payload)
    response.raise_for_status()
    return response.json()   # contains access_token, refresh_token, expires_in

Resource Server

The resource server hosts the protected resources and validates access tokens before granting access. It trusts tokens issued by the authorization server.

Real‑world example: The wearable device’s API (e.g., https://api.wearfit.com/v1/steps) is the resource server. When the fitness app presents a token obtained from Google, the resource server checks the token’s signature, scope, and expiration, then returns the step count.

Key points: - Validates tokens on each request (signature, audience, scope). - Enforces the permissions expressed in the token. - May use a library to decode JWTs or verify OAuth2 bearer tokens.

Minimal Python illustration (resource server)

import jwt  # PyJWT library
from functools import wraps
from flask import request, jsonify

def verify_token(f):
    @wraps(f)
    def decorated(*args, **kwargs):
        auth_header = request.headers.get("Authorization")
        if not auth_header or not auth_header.startswith("Bearer "):
            return jsonify({"error": "Missing token"}), 401
        token = auth_header.split()[1]
        try:
            # Assume token is a JWT signed with the auth server's public key
            payload = jwt.decode(token, "public_key_pem", algorithms=["RS256"])
            request.user = payload  # store user info for the view
        except jwt.ExpiredSignatureError:
            return jsonify({"error": "Token expired"}), 401
        except jwt.InvalidTokenError:
            return jsonify({"error": "Invalid token"}), 401
        return f(*args, **kwargs)
    return decorated

# Example endpoint
@app.route("/steps")
@verify_token
def get_steps():
    # Use request.user to enforce scope, etc.
    return jsonify({"steps": 7421})

Real‑World Example: “Sign in with Google”

1. User (resource owner) opens the fitness app and clicks “Sign in with Google.”
2. Client (fitness app) redirects the user’s browser to Google’s authorization endpoint, including its client ID and requested scopes (e.g., email profile).
3. Authorization server (Google) prompts the user to log in and consent. After consent, Google redirects back to the app with an authorization code.
4. Client exchanges the code for an access token by calling Google’s token endpoint (see Python snippet).
5. Client includes the access token in subsequent API calls to the fitness backend.
6. Resource server (fitness backend) validates the token’s signature and scope, then returns the user’s profile data.

This flow demonstrates how each role interacts without any party ever seeing another’s credentials.

Summary

OAuth 2.0 defines four core roles that together enable secure delegated access:

• Resource Owner: the data owner who grants permission.
• Client: the application requesting access.
• Authorization Server: authenticates the owner and issues tokens.
• Resource Server: validates tokens and serves protected resources.

Understanding each role’s responsibilities helps developers implement OAuth flows correctly, protect user data, and avoid common security mistakes. The “Sign in with Google” example shows a practical, end‑to‑end use case that maps directly to these roles.