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 to securely access third-party applications to user resources without passing a password. The basic idea was that a third-party service could make requests on behalf of the user, but each request was signed cryptographically, to ensure that it is not modified and comes from an authorized customer.
Features of OAuth 1:
- Cryptographic signature of each request (HMAC-SHA1 or RSA-SHA1).
- Used two types of tokens: request token to start authorization and access token to access resources.
- Could work even without HTTPS because the security was ensured by the signature of the request.
- Suitable mainly for server applications and a limited number of authorization scenarios.
OAuth 1 was actively used in services such as Twitter API v1 or older versions of LinkedIn, but due to implementation difficulties and signature problems, 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 the work of developers easier, to allow different types of customers (web, mobile applications, SPA) to easily access user resources without passing a password.
Features of OAuth 2:
- Uses access tokens (access token) and optionally refresh token. Access token short-term, refresh token allows you to continue the session.
- Does not require a cryptographic request signature - security is provided through HTTPS.
- Supports various authorization streams: authorization code (for server web clients), implicit (for SPA), password (for trusted clients) and client credentials (for server-server interaction).
- Much easier to implement and supported by modern APIs (Google, Facebook, GitHub, Microsoft, Stripe, etc.).
When is better to use:
- OAuth 1: If you're working with very old APIs that need it, or in an HTTPS-free environment where query-level cryptography is important.
- OAuth 2: for modern web and mobile applications, SPA, API where HTTPS is guaranteed. Also convenient for third-party customers, because it supports refresh tokens and various authorization streams.
Comparison of OAuth 1 and OAuth 2 in practice
- Difficulty: OAuth 1 is more complex due to signatures, OAuth 2 is simpler and more flexible.
- Safety: OAuth 1 is safe even without HTTPS, OAuth 2 needs HTTPS.
- Flexibility: OAuth 1 is limited, OAuth 2 supports many authorization threads.
- Usage today: OAuth 1 is almost unused, OAuth 2 is the standard for modern APIs and services.
OAuth 1 was about secure authorization without HTTPS, OAuth 2 - about flexibility, simplicity and modern scenarios for web and mobile applications.
This post doesn't have any additions from the author yet.
