OAuth is a mechanism, originally developed by Twitter, to validate the requests sent to a web server by a client application on behalf of a user.
This article attempts to give a simple explanation of the reasons behind the development of OAuth, and the concepts involved.
“Classic” validation using a cookie
To provide the intended service, a web server might need to keep private user data such as images, email messages, documents, etc.
To ensure that a given document can only be accessed by the owner, many sites implement a validation mechanism that relies on the use of a session cookie. The image below is an attempt to represent graphically the steps involved in this type of validation:
- The server sends a login form to the user
- The user fills the form with a username and password, and sends it back to the server
- If the username/password match the credentials stored in the server database, the server generates a session cookie and sends it to the client.
- For every subsequent request sent by the client, the session cookie is attached to the request. Using the cookie, the server matches the request with the user, and grants or denies access to the resources requested, based on the access rights of the authenticated user.
The username/password validation mechanism described above has a potential security risk: The credentials are sent through the internet, and the data packets with the username and password could be captured and analyzed by a hacker.
The secure http protocol HTTPS is usually employed to avoid this risk. With HTTPS, data packets are encrypted before being transmitted using a key provided by the server, and can only be unencrypted by the server that generated the encryption key.
Validation with digital signature
An alternative to the validation mechanism using a cookie is the validation by means of a digital signature. In this case, the client is provided with a public/private key pair after validating with username and password. Then, for every message being sent, a signature is generated based on the content of the message, encrypted with the private key, and attached to the message:
To verify the validity of the received message, the server generates the signature with the same algorithm used by the client, un-encrypts the signature received using the public key, compares both. and only validates the message if they match.
Delegating the validation
The problem that these validation mechanism do not solve is the case when the user wants to grant access to the data stored in a server to a different application running on another server.
For instance, the user stores some Word documents in server A, and wants to run a Word-to-PDF converter service that runs on server B. The most straightforward way to implement this would be that server B asks the user to provide the username and password to validate on server A.
This option has many security issues. For once, server B would have access to all documents of the user stored in server A. In the most extreme case, it could even change the password and prevent users from accessing their own data.
Granting access with OAuth
The OAuth validation mechanism has been developed to solve this problem of delegating the validation to an application. Instead of providing server B with the username and password to access server A, it is provided with an “access authorization”. This authorization may include some restrictions to the resources that can be accessed, or have a limitation on the time of validity.
Besides, messages exchanged between server A and server B are digitally signed to ensure their authenticity
The complete flow in the OAuth scheme is:
- Server B ( acting as the client on behalf of the user) has been previously registered in server A (the server), and has obtained a public/private key pair. In OAuth, these keys are known as “customer key” and “customer secret”. All messages sent from server A to server B are digitally signed using these credentials.
- The user connects to the client, and requests some kind of processing of a document residing on the server.
- The client requests temporary credentials to the server. These will be used to sign a message requesting the “access credentials”
- The client redirects the user’s browser to the server. The server sends a login form to the user, and once validated, ask the user to confirm the access authorization requested by the client.
- The server sends the “access credentials” to the client.
- The client sends to the server requests to access the desired resources. The requests are signed with the access credentials, that identify the user, and also with the customer key/secret credentials that identify the client.