A primer on delegated access
OAuth, short for “open authorization”, is a widely used protocol that allows users to grant third-party websites or applications access to their personal information on other websites. It provides a mechanism for secure access delegation across the internet.
History Class
Prior to the creation of OAuth, sharing of information with third-parties would rely on some form of direct authentication. Commonly, a user would share login credentials with the third party application. That application would store the user’s credentials then login as though it were the user. This approach is not without shortcomings. Sharing credentials increases the likelihood that those credentials are compromised, leaving the user vulnerable to risks. If that user updated their credentials, all third party applications that login on behalf of the user would also have to update their understanding of the credentials. All in all, this pattern of direct authentication was not sustainable.
In late 2006, Twitter began investigating ways to securely share user information with third-party applications. A small working group came to a conclusion that no such mechanism existed at the time, so they began working on a draft. The draft gained consensus in the community and eventually landed as an official protocol at the end of 2007. OAuth1.0a was born!
As OAuth1.0 gained traction, developers began to point out some implementation pain points. OAuth1.0 was built for web applications, so native and desktop applications were forced to use cumbersome patterns to authorize users. The initial specification also required cryptographic signatures on all calls to resource servers, which proved complex and insecure.
A few years later, the OAuth specification was completely rewritten. The rewrite, known as OAuth2.0, was not backwards compatible with the original design. It was intended to be a complete replacement rather than a successor. It introduced more authorization flows to better support native applications, removed cryptography requirements and instead relies on the HTTPS protocol for sharing data securely, and more clearly communicated roles and responsibilities of the different components involved in authorization.
OAuth2.0 has seen widespread adoption across the identity community and is now the dominant player in delegated access. Since OAuth2.0 is more commonly used in the industry, any mention of “OAuth” for the remainder of this post actually refers to OAuth2.0.
Roll Call
Now that we have the history out of the way, let’s talk about the key components of the OAuth specification. There are four main actors in the OAuth world. They are the “client”, the “resource owner”, the “authorization server”, and the “resource server”.
The first actor is the ”client”. The client is a website or application that wants access to some protected information. It makes requests on behalf of the resource owner and with its authorization.
The next actor is the “resource owner”. The resource owner is the entity capable of granting access to protected information. If the protected information is your personal data, then that resource owner may be you. If it is some organization data, then the resource owner may be an administrator or someone else with elevated privileges.
The next actor is the “authorization server”. The authorization server ensures that the client’s request to the protected resource has been authorized by the resource owner. In return, it gives the client a token that grants it access to the protected information.
The fourth and final actor is the “resource server”. The resource server is the maintainer of the protected information. When the client makes a request for information, the resource server checks its token and grants or denies access accordingly.
OAuth 101
So far, we’ve talked briefly about the history of OAuth and why it exists, as well as covered the central components to the protocol. Now we’re ready to get into the actual nuts and bolts of OAuth.
As mentioned earlier, OAuth is a way to securely share protected information with a third party without also sharing login credentials. At its most basic form, the OAuth flow goes something like this: A third party website or application (a “client”) wants access to your information (“protected resource”). You (the “resource owner”) can allow or deny access. If you allow access, the third party is given a token that grants it access (from the “authorization server”). The third party can then flash its access token and receive your information from its maintainer (“resource server”).
The OAuth2.0 specification lays out a few different ways to establish trust and exchange access tokens. While the approaches differ in the credentials exchanged, the general flow remains the same.
Extra Credit
Now it’s perfectly understandable that you may not want to grant a client full access to your protected resource. Maybe you want to restrict access to certain resources. Or maybe you want to give some clients full access while others get a limited subset. The OAuth specification acknowledges this too. To support varied restrictions based on a per-client basis, the spec includes the concept of “scopes”. Scopes define subsets of information accessible to a client. The client can have any number of scopes associated with their token, and will only see those resources covered by the scopes.
A Real World Scenario
If you think back to our previous post in this series, you may recall a scenario about an educators conference. When you arrived at the conference, you were given a lanyard that mapped on your role as an educator. Inside the expo hall we’re a series of lectures aimed at various roles in education. In order to access those lectures, you had to have the appropriate role. That is, teachers were only able to attend teacher lectures and administrators could only attend the administrator lectures.
When you arrived at the venue, you were given a lanyard by event staff. Here, the lanyard represents your access token, and the staff presenting it are acting as authorization servers. The event coordinators have already vetted your identity and granted you access to lectures. The coordinators here are resource owners, and lectures are the protected resources. Your color-coordinated lanyard is similar to a scope since it defines what you can access.
Simply put, OAuth is a well-known protocol that allows one service to request information from another on behalf of a user. It provides users and applications a secure and widely accepted mechanism for exchanging information. The OAuth protocol outlines a number of different flows for exchanging user information, but they all perform the same general function. Clever and our application partners take advantage of the OAuth protocol to safely and securely share information about our users. As resource owners, our school districts remain in complete control of their district’s information and can grant or deny access as they see fit. In the next edition of this series, Clever’s Auth team will review a companion protocol to OAuth, OpenID Connect.
Want to learn more about authorization and authentication? Read our first post discussing their differences.