OAuth 1.0 versues OAuth 2.0
Introduction to OAuth
Let’s consider OAuth as a car’s valet key. Unlike a regular key that allows the holder unlimited access, a valet uses this valet key only to take the car for a temporary spin without having access to the glove compartment or trunk. OAuth enables an end user’s account information to be used by third-party services like Amazon, Facebook, Google, Instagram, LinkedIn, Netflix, Paypal, Microsoft, Twitter, etc. These companies work with many third-party applications and frequently permit users to share their credentials within apps like news websites, blogging platforms, online video games, etc.
For Instance, when logging into another app on Facebook, a user may click the Facebook login button. Then, Facebook automatically authenticates them, and the website grants them access with permission from Facebook. OAuth is also used for email authentication, like Gmail, in which a web service gains access to protected resources within another device, allowing the user to access two different services with one login.
OAuth version:
OAuth 2.0 is a completely rewritten framework of OAuth 1.0, and the 1.0 version is regarded as a protocol that uses different terminology and terms. The main difference in function is how both versions categorize duties and end-user experience.
OAuth 1.0 has a consumer, service provider, and user, and it doesn’t explicitly separate the roles of the resource server and authorization server.
On the other hand, OAuth 2.0 has a client, authorization server, resource server, and resource owner. That’s why these versions don’t have backward compatibility. OAuth 2.0 offers specific authorization flows for web applications, desktop applications, mobile phones, smart devices, and non-browser-based applications such as API-based services.
OAuth 1.0
⇒ user A want App 1 to access data in App 2
⇒ App 1 send request to connect with App 2 initiated by user A
⇒ App 2 accepts the request from App 1
⇒ App 2 sends a temporary token to App 1
⇒ App 1 redirect user A to login or preformatted urls can also be used
⇒ After user A successfully authenticates on App 1, App 1 ask for approval for user A to grant permission to App 2 to access App 2’s resources
⇒ On granting the approval, App 1 is informed
⇒ App 1 requests App 2 for a new access token using Temporary Token
⇒ App 2 approves the request the request & send a new access token
⇒ App 1 can now access App 2’s data using new access token
OAuth 2.0
⇒ user A want App 1 to access data in App 2
⇒ App 1 requests access to App 2 from authorization server
⇒ user A authenticates to authorization server with this credential received in step above & return authorization grant to App 1 to access data on App 2
⇒ Now, App 1 requests access token from Authorization server using the authorization grant which user A gave in step 3 above
⇒ Authorization server validates the request & sends an access token to App 1
⇒ App 1 can now access data in App 1 with access token
Why OAuth 2.0 ?
- Better support for non-browser applications
OAuth 1.0 has been designed focusing on the interactions of inbound and outbound messages in web client applications. Therefore, it is inefficient for non-browser clients. OAuth 2.0 has addressed this issue by introducing more authorization flows for different client needs that do not use web UIs.
- The separation of roles
Handling resource requests and handling user authorization can be decoupled in OAuth 2.0. It has clearly defined the roles involved in communication which are client, resource owner, resource server, and authorization server.
- The short-lived access token and the refresh token
In OAuth 1.0, access tokens can be stored for a year or more. But in OAuth 2.0, access tokens can contain an expiration time, which improves the security and reduces the chances of illegal access. And it offers a refresh token which can be used to get a new access token at the access token expiration without reauthorizing.
- Reduced complexity in signing requests
OAuth 1.0 needs to generate a signature on every API call to the server resource and that should be matched with the signature generated at the receiving endpoint in order to have access for the client. OAuth 2.0 do not need to generate signatures. It uses TLS/SSL (HTTPS) for communication.
