OAuth2 Roles — Resource Owner, Client, Authorization Server, Resource Server

In this tutorial, you will learn about OAuth2 Roles. We cover key concepts, practical examples, and best practices to help you master this topic.

OAuth2 defines four roles — Resource Owner, Client, Authorization Server, and Resource Server — each with distinct responsibilities in the authorization flow.

What You'll Learn

Each role's responsibilities, how they interact, and real-world examples of each role.

Why It Matters

Understanding roles is essential for implementing any OAuth2 flow. Misidentifying roles leads to wrong grant type selection and security vulnerabilities. Every OAuth2 interaction involves all four roles.

Real-World Use

When Doda Browser requests access to Google Drive: you (Resource Owner) use Doda Browser (Client) which redirects to Google Accounts (Authorization Server) to get tokens for the Google Drive API (Resource Server).

sequenceDiagram
    participant RO as Resource Owner (User)
    participant Client as Client App
    participant AS as Authorization Server
    participant RS as Resource Server

    Client->>AS: Redirect user for authorization
    RO->>AS: Authenticate + consent
    AS->>Client: Authorization Code
    Client->>AS: Exchange code for token
    AS->>Client: Access Token
    Client->>RS: API call + Access Token
    RS->>Client: Protected Data
    Client->>RO: Display result

Role Responsibilities

Resource Owner

The user who owns the data. Their only action is authenticating and granting or denying consent. The resource owner's credentials never reach the client.

Client

The application requesting access. It initiates the flow, obtains consent, and uses the access token. The client must be registered with the authorization server.

Authorization Server

The core of OAuth2. It authenticates the resource owner, obtains consent, issues tokens, and optionally manages refresh tokens. Must be highly secure.

Resource Server

The API that hosts protected data. It accepts access tokens, validates them (with or without introspection), and returns data. Does not issue tokens.

Client Types

Common Mistakes

1. Confusing Client and Resource Owner

The client is the application, not the user. The resource owner is the user. These are separate roles with separate responsibilities.

2. Making the Resource Server Issue Tokens

The resource server validates tokens but does not issue them. Token issuance is the authorization server's responsibility.

3. Not Registering the Client

The client must be registered with the authorization server to get a client_id and (for confidential clients) client_secret.

4. Merging Authorization and Resource Server

While they can be the same service, separating them allows independent scaling and specialized security.

5. Ignoring the Resource Owner in Machine-to-Machine

In client credentials, there is no resource owner. This is the only grant without user involvement.

Practice Questions

1. What are the four OAuth2 roles?
2. Which role issues access tokens?
3. Which role validates access tokens?
4. What is the difference between confidential and public clients?
5. In Client Credentials grant, which role is missing?

Answers:

1. Resource Owner, Client, Authorization Server, Resource Server.
2. The Authorization Server issues access tokens after authentication and consent.
3. The Resource Server validates access tokens (directly or via introspection) before returning data.
4. Confidential clients can keep a secret (backend server). Public clients cannot (mobile app, SPA).
5. The Resource Owner — Client Credentials is machine-to-machine with no user involved.

Challenge: Draw a sequence diagram for a complete OAuth2 Authorization Code flow, labeling each message with the source and destination role.

FAQ

Mini Project

Role-play a complete OAuth2 flow: write three Python scripts — one for the authorization server (issues tokens), one for the client (redirects user, exchanges code), and one for the resource server (validates tokens, returns data).

What's Next

Now learn the most important grant type: Authorization Code Grant in detail.