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 secure access of third-party applications to 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 for initiating authorization and access token for accessing resources.
- Could work even without HTTPS, as security was provided by the request signature.
- Was mainly suitable 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 the complexity of implementation and signature issues, it was gradually replaced by OAuth 2.
OAuth 2
OAuth 2 appeared 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 apps, 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, refresh tokens allow 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 hardly 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.
