What is OAuth and Why Should I Use It
https://en.wikipedia.org/wiki/OAuth
So you’re designing an application, service, and/or API and you’re wondering what you should do to support user authentication. In this day and age, we as developers have to be ever vigilant when it comes to securing our platforms and applications. It’s not very significant to just check a username and password, you also need to be able to determine what features will be available and when depending on system-level and user-level permissions. You’re interested in the how — the authorization protocol with which users will interact with and with which the server will have the ability to “secure delegated access” to resources on behalf of the resource owner.
Let’s start off by defining a few terms:
- noun au·then·ti·ca·tion (/ôˌTHen(t)iˈkāSH(ə)n/)
the process or action of verifying the identity of a user or process. - noun au·thor·i·za·tion (/ˌôTHərəˈzāSH(ə)n/)
the function of specifying access rights/privileges to resources. - noun re·source (/ˈrēˌsôrs,rəˈsôrs/)
a record, document, file, or other digital entity.
It’s important to understand the difference between authentication and authorization.
Authentication is simply providing a set of credentials so the server can check to confirm you are who you say you are and that you indeed have valid credentials.
Authorization follows the authentication process and ensures once we’ve determined the user’s credentials are correct that we can then define and enforce access control and permissions to hosted resources.
OAuth is a token-based authorization framework, designed specifically to work with HTTP. It itself is not an API, a service, or a package. While there’s an abundant supply of open source and off-the-shelf implementations, OAuth is an open standard, a specification for how developers should enact upon their implementations. It’s commonly used by companies such as Google, Facebook, Twitter, Amazon, Microsoft, etc. as a way to allow their users to grant other websites or services access to their information without giving them their password. Additionally, OAuth allows 3rd party developers to specify what information the user might be required to share in order to use the service, and what information might be optional to share. The user then has the ability to conditionally not share their birthday associated with their Twitter account for example with YetAnotherTwitterApp, or to just not allow the authorization with the 3rd party all together. If you use any of these sites or services, you’ve probably seen a confirmation prompt similar to what I’m referring to.
There are two versions of OAuth: OAuth 1.0a and OAuth 2.0, but zero compatibility between the two of them. They are completely different specifications and implementations. Luckily the choice is easy, OAuth 2.0 is the most widely used form of OAuth. They obviously built upon the problems they faced with 1.0. I won’t bother covering the differences, makes the most sense to use the latest and greatest here.
Here’s an example from Google:
In the above screenshot, you can see a confirmation dialog from Google’s platform after being redirected from a 3rd party application (likely some calendar app in this case) to Google’s servers themselves in an attempt to request access to the user’s Google account (name, email, calendars, etc) on behalf of the user. After being redirected to Google (or any OAuth server for example) if you’re not already logged in you’ll be prompted to do so, and you’ll accept the requested access and be redirected back to the 3rd party app. That app would then be able to access the allowed resources from your Google account using what’s called an access token.
Diving in Deeper
OAuth is comprised of four different roles:
- Resource Server
A REST API for example, an HTTP server where users can create, modify, or delete records, documents, and/or files. - Resource Owner
An individual user who maintains ownership of resources they’ve created or modified on the server, and who authorizes a 3rd party application to access their account. The 3rd party application has limited access to the user’s account based on the “scope” of the authorization granted. - Client
3rd party application that wants to access the user’s account. Before it’s able to do so, the resource/authorization server and the resource owner must authorize the request. Every client must be registered with the authorization server, and will be provided it’s own unique credentials (client_id and client_secret) for its own authentication (more below). - Authorization Server (often times the same as the resource server)
Sometimes, it’s desirable to pull out the authorization server from the resource server and deploy it as a dedicated instance, especially in distributed environments.
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
- The 3rd party application requests authorization from the service and user to access resources owned or accessible by the user.
- Assuming the user authorizes the request, the 3rd party application receives an authorization grant.
- Now that the 3rd party application has been authorized, it’s able to request an access token from the authorization server by presenting the now obtained authorization grant provided by the user, as well as its own authentication credentials as a client.
- If the 3rd party application is able to authenticate and the authorization grant is valid, the authorization server generates a unique access token, associated with the authorization grant permissions and resource owner for future use and validation.
- The application can now request resources from the resource server utilizing the access token in requests.
- With a valid access token, the resource server serves up these protected resources that have now been fully authorized by the user and the server for access.
There are a few different grant types other than authorization that can be utilized depending on the use cases. By and large though, the authorization grant type is the most commonly used OAuth grant type, especially for public services and APIs.
The Password Anti-Pattern
So OAuth is cool and all, it definitely sounds like an interesting solution. Let’s understand a little more about why using an authorization protocol like OAuth is important.
As we discussed above, the Internet is huge and only ever expanding. We use services and platforms on a daily basis. And we provide access between some of these services and platforms so we can connect and transfer information securely between them. With the advent of APIs and SDKs, development of applications expands rapidly to not just web, but mobile and desktop as well. While these APIs are really valuable and convenient (sometimes/rarely), it becomes difficult to provide this interoperation of services in a way that safeguards the user’s security. Traditional HTTP services utilize HTTP Basic Auth or other login-based session-related authorization workflows, but these usually require passing your credentials through a 3rd party instead of directly to the authentication/resource server. Services/APIs generally require authentication and authorization for sensitive or user-specific features. While this simple login-based means of implementing authentication is easy, it has serious security concerns.
One of the biggest security concerns with simple username/password authentication is that there isn’t an easy way for a user to revoke access or permissions from a 3rd party application. Users are left with only one option usually: reset their password. Additionally, if a vulnerability or security bug is found in a 3rd party application and made known, the developers of a platform or service such as Twitter can (temporarily) suspend/revoke/disable said 3rd party application (OAuth Client) to protect all of their users who might be using it until a security patch is deployed. Another security concern with simple authentication is the lack of ability to control access to resources and information. There’s no way to control how much information the 3rd party application is allowed access to. It’s either all or nothing.
Users want and deserve the ability to provide granular access, but also to revoke any unauthorized access at a future time, and all without having to provide their password. Developers want to provide this capability for their users and provide access to and from a variety of popular web services and platforms, but it becomes challenging when there are so many different authentication and authorization protocols. OAuth brings a standards-based solution to the table, something all developers in the community can and have circled around. It’s the first step towards a unified, standardized specification for password-less authorization for web, desktop and mobile applications.
Hopefully this has been an informative introduction to the OAuth authorization specification and standard and has helped illuminate the motivations behind it and why you should consider using it for your next project.
Author:
Matt Helm
Senior Software Engineer, ThreatQuotient
References
- OAuth and OAuth WRAP: defeating the password anti-pattern — Ars Technica
https://arstechnica.com/information-technology/2010/01/oauth-and-oauth-wrap-defeating-the-password-anti-pattern/ - An Introduction to OAuth 2 — DigitalOcean
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2 - What the Heck is OAuth? — Okta Developer
https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth - OAuth — Wikipedia
https://en.wikipedia.org/wiki/OAuth - RFC 674 — The OAuth 2.0 Authorization Framework
https://tools.ietf.org/html/rfc6749
