What is OAuth 2.0

• Authorization Code: redirect → code → server exchanges for access_token
• PKCE (Proof Key for Code Exchange): for public clients, defends against stolen codes
• Client Credentials: service-to-service, no user, via client_id + client_secret
• Device Code: for devices without browsers — user confirms on phone
• Scopes: limit what the token can do (read:email vs write:all)

Authorization: Bearer eyJhbGciOi...

• JWT
• CSRF
• Webhook

OAuth 2.0 defines several flow types to accommodate different use cases and environments. Understanding these flows is crucial for implementing OAuth securely and effectively.

• Authorization Code Flow: This flow is primarily used for web applications. It involves redirecting the user to the authorization server, where they log in and grant permissions. The server then redirects back to the application with an authorization code, which the application exchanges for an access token. This flow is secure as the access token is never exposed to the user agent.
• PKCE (Proof Key for Code Exchange): An enhancement to the Authorization Code Flow, PKCE is designed for public clients, such as mobile and single-page applications (SPAs). It adds an additional layer of security by requiring a code verifier and a code challenge, preventing interception of the authorization code.
• Client Credentials Flow: This flow is used for server-to-server communication. Here, the application directly requests an access token using its own credentials without user interaction. It’s commonly used for accessing APIs where user context is not required.
• Device Flow: This flow is intended for devices with limited input capabilities, such as TVs or IoT devices. The user is provided with a code and directed to a URL on another device to enter it. Once authenticated, the device receives an access token.

Each flow serves a specific purpose and is designed to mitigate risks associated with different types of applications and usage scenarios.

Implementing OAuth 2.0 can vary based on the flow type chosen. Below are examples for the Authorization Code Flow and Client Credentials Flow.

Authorization Code Flow Example

1. Redirect to Authorization Server:

2. Exchange Authorization Code for Access Token:

3. Use Access Token to Access Protected Resource:

Client Credentials Flow Example

1. Request Access Token:

2. Use Access Token to Access API:

These examples illustrate how to use OAuth 2.0 flows for different scenarios, ensuring secure access to resources.

OAuth 2.0 and JSON Web Tokens (JWT) are often discussed together, but they serve different purposes in the realm of web security.

OAuth 2.0 Overview

OAuth 2.0 is primarily an authorization framework. It allows applications to gain limited access to user accounts on an HTTP service, without exposing user credentials. OAuth 2.0 defines how tokens are obtained and used but does not specify the format of these tokens.

JWT Overview

JSON Web Tokens (JWT) are a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure. JWTs can be used as access tokens in OAuth 2.0 flows.

Key Differences

• Purpose: OAuth 2.0 is an authorization protocol, whereas JWT is a token format.
• Token Structure: OAuth 2.0 does not define how the tokens should be structured, while JWT has a specific structure that includes a header, payload, and signature.
• Use Case: OAuth 2.0 is used to delegate access, while JWT can be used for both authorization (as in OAuth) and information exchange.

In summary, OAuth 2.0 is a protocol for authorization, while JWT is a token format that can be used within that protocol. Understanding their roles helps in building secure applications.