The OAuth Credential Headache

The Problem

Alice wants to book a budget vacation, and rather than make her own reservations at her preferred travel providers FlyAir, StayInn and DriveCar, she relies on BudgetTravel to watch over prices twenty four hours a day and to act when the prices are low. Now since she cannot be on-line waiting all the time, Alice needs to allow BudgetTravel to act on her behalf, but she does not want to give up her credentials to FlyAir, StayInn and DriveCar.

Luckily for her all parties have recently adopted the OAuth delegated authentication protocol which was designed to solve just this problem. When she sets up the delegated authentication, BudgetTravel redirects her browser to FlyAir where she is asked to authenticate and give permission to FlyAir to divulge her data to BudgetTravel. She repeats this process with StayInn and DriveCar. Once Alice has finished the delegation, BudgetTravel can access each of the providers directly. We make the following observations on the OAuth protocol:

  • As part of this process BudgetTravel needs to have obtained OAuth credentials from FlyAir, StayInn, DriveCar, and the hundreds of other such travel providers. And each travel provider has to provide an OAuth credential to each of the travel agencies it deals with.
  • The above credentialing headache is particularly ironic since OAuth recommends that the parties use SSL for transport level security, which implies that each of these parties already has a digital credential (the SSL certificate) that the other party explicitly or implicitly trusts.
  • Let us assume that BudgetTravel and FlyAir are both very popular. It is likely that they are performing a similar ‘mashup’ for many different users. As currently specified, BudgetTravel would have to re-authenticate itself to FlyAir each time, and FlyAir would have to verify the credentials for each instance of the mashup. If the public-key version of OAuth authentication is used, the performance overhead could be significant.

Let us return to our theme of “looking behind the browser”. OAuth recommends that Alice’s session with BudgetTravel be protected with SSL at the transport level, so Alice’s browser has authenticated BudgetTravel. Yet, this assertion cannot be communicated by Alice to FlyAir (remember that Alice cannot be trusted), because FlyAir cannot “look behind her browser”. The identical problem is true in reverse; even though Alice’s session with FlyAir is protected by transport level SSL, and her browser has authenticated FlyAir, this assertion cannot be securely passed to BudgetTravel.

The MashSSL Solution to OAuth Credential Management

Again, there are multiple solutions possible. We will describe two:

  1. The OAuth Consumer and Service Provider run MashSSL between themselves through the user's browser. At this point they have a shared master-secret. They then run the OAuth protocol with the signature method set to PLAINTEXT and with all OAuth parameter values encrypted with the master-secret. They can safely set the signature method to PLAINTEXT as they are getting their security from the underlying MashSSL protocol. This would be very similar to running "two legged OAuth" over a mutually authenticated transport level SSL session.
  2. Another method would be to simply send the MashSSL handshake messages along with the OAuth messages (again with the signature method set to PLAINTEXT). In this case the first OAuth handshake (asking for the request token) would go through the user's browser instead of directly between the servers. OAuth has six handshake messages before the OAuth access-token can be used. The first four carry the MashSSL messages.

The entire credential management problem simply goes away. Participants use SSL certificates, which OAuth anyway recommends they have. Observe that anyone who examines the use of these protocols together can see obvious optimizations that can be made to the OAuth protocol once it can assume a secure mutually authenticated pipe between the Consumer and the Service Provider through the user's browser. In our implementations, we have not made these optimizations as our goal is to show how MashSSL can underlie OAuth without requiring any changes to the latter.

Note that the same master secret can also be used for direct application to application communications. In effect the user is setting up and authorizing the connection after which further communications can in typical OAuth style happen server to server.