In this article I will try to explain different types of authorization flows that have been tried to solve the problem of the user giving her consent to a client for accessing some of her resources on another server.
I will go through several authorization frameworks starting with HTTP Basic Authentication (yes you read it right! Authorization and authentication was hand in hand at this stage). The dawn of authorizing third party applications started by Yelp. Flickr tried to solve the problem with its API called FlickrAuth that used “frobs” and “tokens”. Google’s own implementation was AuthSub. Yahoo! created BBAuth which is short for a browser based auth. Facebook did not move a lot and just used MD5 signed requests.
HTTP Basic Authentication
HTTP Basic Authentication was in use for some time. It mostly depended on client-server architecture where clients make requests to the resource server with username and password. RFC 7235 defines the HTTP Authentication framework. The framework’s authentication flow is called challenge and response flow. Particularities of the HTTP Basic Authentication scheme are also defined in RFC 7617 as an extension to RFC 7235.
Here how the HTTP Basic Authentication challenge and response flow works:
Client makes a HTTP request to a server.
Server responds to a client with 401 (Unauthorized) response status together with information on how to authorize with a WWW-Authenticate response header.
Client then makes another request with Authorization request header with the credentials. The credentials are usually taken from the user by the client with a password prompt.
Courtesy to Mozilla Foundation
There are several drawbacks to this flow. The password is sent over the wire in base64 encoding which can easily be converted to plain text. Also in each request password is repeatedly sent causing a larger attack window. The password is also cached by the web browser leaving the CSRF (Cross Site Request Forgery) attack possibilities wide open.
You can of course use SSL and make your request over HTTPS however even though the password is safe during transit it will be stored or transferred somewhere else in plain text.
The real problem with this method is actually during the authorization of third-party applications to gain access to resource servers. Client has to collect user credentials in plain text and administer challenge and response flow with all aforementioned drawbacks. At the end, the application will gain full access to the account. There is no limiting the access to designated resources.
Users can only revoke access by changing the password and as a user you never know if the client is vulnerable to attacks or it will do additional things to your account. This is how Yelp was working.
Later on Flickr came with an auth api called FlickrAuth. Authentication and authorization was being served from the same API.
As you can see from the diagram, FlickrAuth was asking the user's permission on its own rather than asking the client the user name and the password. Therefore there is no need anymore for a third-party client to store the user’s credentials. Instead client uses auth token to access user’s resources in resource server.
FlickerAuth had similarities with OAuth however there were also a lot of shortcomings.
First of all if the api key is somehow leaked or exposed any malicious client can ask for auth token. There is no way for the server to know if the client is genuine one or not. There was no equivalent of an api secret. Api key was public to developers and the like.
Secondly FlickrAuth was giving the client permission on the whole level. Account level access was only read, write or delete. Therefore any client who had the consent of the user had ultimate accessibility over all resources the user had. Neither resource level restrictions nor scope were in place.
Third, the FlickrAuth was giving the auth token for an unlimited time. Once you are in you are always in. At any moment in time if the auth token is stolen the only way to revoke all access is to revoke the third-party client from your consent list. Of course if you are lucky enough to know that the auth token was compromised.
Similar to FlickrAuth, Google as well tried to solve the third party application authorization problem with an "auth token" with an authorization API called AuthSub.
AuthSub flow also starts like FlickrAuth. Once user initiates to give permission to the client, the client constructs the appropriate AuthSub URL and then sends the user to that URL so they can log in; the AuthSub sends the user back to URL on client’s site that the client specified, and returns a one-time-use token; client optionally exchanges that token for a session token; then client sends the token in the Authorization header with each request that the client sends to the service.
Authorization flow was improved in contrast to FlickrAuth in several areas. First one was in the “application identity” domain. Application identity is the identity of the client that can be confirmable by authorization server. In FlickrAuth all we could use was the “api key”. In AuthSub however, the client had to create a self-signing RSA private key and public certificate in addition to registering the client application to the server.
Second was an improvement on the scope level. In authorization terminology “scope” determines the token access to the user’s data. You can define the scope as such that at the end you can restrict access to some resources of the user and allow some others.
Another improvement was on the time that the token can be valid. AuthSub provided two options. One was single-use token in which an access to the resource can happen only once and the other one was session tokens which was providing unlimited time of access. Alas an unlimited session token posed several security risks while storing the token on cookie level. Regardless, the single-use token concept was there to prove a good point.
Yahoo developed BBAuth (Browser Based Authentication) more or less at the same time as Google. And the flow is also more or less the same. The below schema can briefly explain the flow. The first time a user visits the third party web application, the web application redirects the user to a specially constructed Yahoo! URL where the user can log in and grant the third party application permission.
As the name suggests BBAuth was only supporting web based applications and until OAuth none of the above was supporting desktop or mobile applications.
Before OAuth came to existence there were also some other efforts to solve third-party authorization problems. Those I have mentioned above are only some of the significant ones. However, I believe, it is enough to prove the point that all of those above tried to solve the same problem on a proprietary level. But at the end their needs were the same.
The first need is that any authorization server needs to know the identity of the third-party application. Most of the time as a third-party application developer it is not enough to register yourself to the authorization server and receive an api-key.
Api-keys in nature are more prone to be shared, stolen or lost. In these cases authorization servers cannot really be sure who is making the request. Therefore “application identity” is one of the first challenges of any authorization flow.
As we can see above authorization flows another challenge is how to restrict resource access even though the third-party application earned to have auth-token. Restricting access on read-write-delete level, on selective resource level or on time/expiration level poses another challenge on its own. “Scope” parameter was one of the first examples of its kind.
These challenges and needs in mind all these developers realized the common goal and came together. By 2007, the first draft of OAuth1 was published and it was deployed at several companies.
In the next article, we will finally dive into the secrets of OAuth protocol.