Table of contentsClick link to navigate to the desired location
This content has been automatically translated from Ukrainian.
OAuth 1
OAuth 1 was developed in the early 2000s as a way for third-party applications to securely access user resources without sharing the password. The main idea was that a third-party service could make requests on behalf of the user, but each request was cryptographically signed to ensure that it was unaltered and came from an authorized client.
Features of OAuth 1:
- Cryptographic signature for each request (HMAC-SHA1 or RSA-SHA1).
- Used two types of tokens: request token to initiate authorization and access token to access resources.
- Could work even without HTTPS, as security was provided by the request signature.
- Primarily suited for server-side applications and a limited number of authorization scenarios.
OAuth 1 was actively used in services like Twitter API v1 or older versions of LinkedIn, but due to its complexity in implementation and signature issues, it was gradually replaced by OAuth 2.
OAuth 2
OAuth 2 emerged in 2012 as a simplified, more flexible, and modern version of the protocol for authorization and access to resources. Its goal is to make developers' work easier, allowing different types of clients (web, mobile applications, SPA) to easily access user resources without sharing the password.
Features of OAuth 2:
- Uses access tokens and optionally refresh tokens. Access tokens are short-lived, while refresh tokens allow for session continuation.
- Does not require a cryptographic signature for requests - security is provided through HTTPS.
- Supports various authorization flows: authorization code (for server-side web clients), implicit (for SPA), password (for trusted clients), and client credentials (for server-to-server interactions).
- Much easier to implement and supported by modern APIs (Google, Facebook, GitHub, Microsoft, Stripe, etc.).
When to use what:
- OAuth 1: if you are working with very old APIs that require it, or in an environment without HTTPS where request-level cryptography is important.
- OAuth 2: for modern web and mobile applications, SPA, APIs where HTTPS is guaranteed. Also convenient for third-party clients as it supports refresh tokens and various authorization flows.
Comparison of OAuth 1 and OAuth 2 in practice
- Complexity: OAuth 1 is more complex due to signatures, OAuth 2 is simpler and more flexible.
- Security: OAuth 1 is secure even without HTTPS, OAuth 2 requires HTTPS.
- Flexibility: OAuth 1 is limited, OAuth 2 supports many authorization flows.
- Usage today: OAuth 1 is rarely used, OAuth 2 is the standard for modern APIs and services.
OAuth 1 was about secure authorization without HTTPS, OAuth 2 is about flexibility, simplicity, and modern scenarios for web and mobile applications.
This post doesn't have any additions from the author yet.
