In our last blog post on web authentication, we looked at the SAML protocol. While SAML provides the capability to manage user identity between applications, it has largely been replaced by the more flexible and lightweight OAuth 2.0 protocol, which is the focus of this and the following blog posts.
What is OAuth 2.0?
The OAuth (1.0) protocol was originally created in 2007 by a small community of web developers who wanted to solve the common problem of enabling delegated access to protected resources. This group saw the increase in cloud computing and mobile development, and realized a need for a mechanism for not only cross application identity management, but also protecting individual resources across technologies - something that remained lacking in SAML. Although this homegrown movement was not formalized by any official Internet Engineering Task Force (IETF) specification and wasn’t widely adopted because of the differing implementations, it did act as the first step towards the formalized OAuth 2.0 spec.
OAuth 2.0 acted as a complete rewrite of the OAuth 1.0 specification. The second version sought to standardize implementation of the protocol while maintaining the goals of OAuth 1.0. Similar to SAML, the main goal of OAuth is to prevent the sharing of credentials; however, OAuth is focused on providing access to resources on a more granular level by separating the roles of client and resource owner
- The resource owner is defined as, “An entity capable of granting access to a protected resource.” (A resource in this case is a digital artifact, like a webpage, an image, a document, or raw data).
- The client is defined as, “An application making protected resource requests on behalf of the resource owner and with its authorization.”This wording specifically implies that the client does not necessarily need to be a browser or server or mobile device, it must simply be an application that is authorized to access a resource on behalf of the resource owner, which we typically think about as a person, or the end-user.
There are two more important roles in the OAuth protocol: the resource server and the authorization server.
- The resource server is the service hosting the resources protected or owned by the user. This service is responsible for granting and denying access to resources based on the interpretation of access tokens, which are string interpretations representing an authorization issued to the client. These access tokens are typically in the form of a JSON Web Token (JWT).
- The authorization server is responsible for issuing tokens to clients after successfully gaining authorization from the resource owner.
How it Works
Now that we’ve developed an understanding of the roles involved in the OAuth protocol, we can look at the general flow of OAuth.
First, the client requests authorization from the resource owner allowing access to certain resources on their behalf. After receiving the authorization from the owner, the client then exchanges the authorization grant for an access token, which it then uses to access the requested resource(s).
How does this appear to the user in practice? Depending on the application, it could look any number of ways to the end user, so let’s take a look at some examples.
Example 1: Website Login
Alice is a user of a photo sharing site. She wants to access her account to see the photos she has uploaded. So, she navigates to the site url and clicks the ‘Login’ button. At this point, the client (her browser) does not know who she is. To identify Alice as the user making these actions, it redirects to the authorization server to identify the user requesting access- this serves as step one in the diagram above.
Alice then enters her credentials into the web form and signs in (step 2). Behind the scenes, Alice’s browser sends the credentials to the authorization server (step 3) in exchange for the access token (step 4). The browser then redirects to the resource server, forwarding along the access token (step 5), to which the browser responds with Alice’s personalized dashboard with her photos (step 6).
Example 2: Connected Application
Although Alice uses the photo sharing site to manage her photo library, she also wants to have them sync to her Facebook account. Luckily, her site provides an integration with Facebook to make this easy.
Alice navigates to the settings menu and selects the, “sync to facebook,” option. Alice is then prompted with a message, “Facebook would like to access your photos,” and has the option to accept or decline. This is step one in the diagram, where Facebook, acting as the client application, is requesting authorization to access Alice’s photos on the photo sharing site.
Wanting to share her photos, Alice clicks, “accept.” This changes a setting on the resource server that will allow requests for Alice’s photos from Facebook to succeed. At some point in the future, Facebook contacts the authorization server to get an access token, and having been granted the privilege of accessing Alice’s photos, uses that access token to copy Alice’s photos to her Facebook account.
Above were just two examples of how OAuth 2.0 can be used in different situations. For each of these different scenarios - and others - OAuth 2.0 defines different flows, or implementations, of the protocol to meet these use cases. Moving forward, we’ll be taking a closer look at the various OAuth 2.0 flows and when to use each of them.
Check back for future posts on OAuth 2.0 in web applications. Have questions? Contact us or join in the conversation below!