OAuth2 Overview: Roles, Flow, Client Registration, Grant Types, and Code Samples

OAuth2 Overview

OAuth is an open authorization protocol that lets users grant third‑party applications access to their data stored on another service provider without sharing passwords. OAuth2 is the second version (RFC 6749) and is not backward compatible with OAuth1.

Roles

Typical roles include the Resource Owner (user), Client (the third‑party app), Authorization Server, and Resource Server. For example, a user logs into GitHub, authorizes Ruby China, and Ruby China receives an access token to read the user’s profile.

Authorization Flow

The client asks the user for authorization.

The user consents.

The client sends the authorization request to the Authorization Server.

The server validates the client and issues a token.

The client presents the token to the Resource Server.

The Resource Server validates the token and returns the protected resource.

Client Registration

Developers must register a client on the Authorization Server, providing:

Application name

Home Page URL

Redirect URI

Client type (confidential or public)

After registration the client receives a clientId and clientSecret.

Client Types

According to the specification:

confidential : capable of keeping credentials secret (e.g., server‑side applications).

public : cannot keep credentials secret (e.g., native apps or browser‑based SPAs).

Four Grant Types

OAuth2 defines four main grant types for obtaining access tokens, each suited to different scenarios.

Authorization Code Grant

The client obtains an authorization code first, then exchanges it for an access token. This flow is the most secure and is used by server‑side web applications.

GET http/1.1
http://server.example.com/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb&scope=read

After user consent, the server redirects back with a code:

https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

The client then exchanges the code for an access token:

POST http/1.1
http://server.example.com/token
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb&clientId=xxx&clientSecret=xyzz

Implicit Grant

Designed for pure front‑end applications that cannot keep a secret. The token is returned directly in the fragment part of the redirect URI.

https://client.example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

Password Grant

The client collects the user's username and password and sends them to the token endpoint. This flow is only suitable for highly trusted applications.

POST http://server.example.com/token
body: grant_type=password&username=johndoe&password=A3ddj3w&clientId=xxx

Client Credentials Grant

Used by machine‑to‑machine applications that have no user context. The client authenticates with its own credentials to obtain an access token.

POST http://server.example.com/token
body: grant_type=client_credentials&clientId=xxx&client_secret=SECRET

Refresh Token

When an access token expires, the client can use a refresh token (if issued) to request a new access token without further user interaction.

Demo Reference

For a practical GitHub OAuth2 demo, see the tutorial by Ruanyifeng: GitHub OAuth2 Demo .