OAuth 1.0

March 03, 2023

For sites without user-driven features that offer API interfaces for their functionality (for instance, a site providing weather data), enabling Client Applications secure API access is often a straightforward process - generating a unique API key for each registered client for them to include in each API request.

But for user-focused sites that wish to allow Client Apps to add extra functionality to their platform, these apps often need access to user data.

Note On Terminology

Before OAuth, Client Apps would often require the user’s Service Provider credentials to function. This meant sharing credentials between the two parties. The security risks of this approach included:

1) Credentials being leaked 2) Inability for users to revoke access to Client Apps 3) Inability to control the user information available to Client Apps

Enabling Client Applications secure access to user resources

OAuth was originally developed as a secure method to allow Service Providers to enable user-related functionality for Client Applications, without sharing credentials.

Using the OAuth protocol, Service Providers authorize Client Apps limited access to resources, varying by the requirements of the Client App, and allow users to easily revoke any previously granted permissions.

Some Service Providers are widely used, established ecosystems (such as Microsoft and Google) that also act as Identity Providers, although any site with user authentication - whether self-hosted or through Identity Providers - can implement OAuth for integration with Client Applications. OAuth is designed for secure authorization of Client Applications, not authentication itself.

In 2007 Twitter was the first major site to adopt OAuth for Client Applications accessing its API.

There are two major versions of the OAuth protocol, OAuth 1.0 and OAuth 2.0.

OAuth 1.0 was found to have major vulnerability and was quickly patched to become OAuth 1.0a, although the version IDs are usually used interchangeably.

OAuth 1.0 flow

1) Registering the Client App

With OAuth 1.0, the process of registering a Client Application for access usually begins with the Client App developer submitting details of their app’s purpose and requirements for review by the Service Provider. Once registered, the Service Provider provides the Client App developers with a Consumer API Key and a Consumer Secret, stored on the Client App’s server.

2) Client App requests a Request Token

When a user wishes to authorize the Client App with the user-specific access it needs, the Client App initiates an API request for a temporary (‘request’) token from the Service Provider. This API request will include the Consumer Key, and several other parameters such as a timestamp and signature algorithm, and the signature created from these parameter values and the Consumer Secret. Since the Consumer Secret is known by the Service Provider, it can verify the request signature, ensuring the request is authentic.

3) User authenticates with Service Provider (if necessary), and authorizes Client App

With the Client App’s request trusted, a Request Token and a Request Token Secret are sent back to the Client App’s server. The server will then redirect the user to the Service Provider’s authorization page, with the Request Token included in the redirect URL, along with a callback URL where the Service Provider will send the user after they have granted permissions to the Client App. Note that any user authentication is made with Service Provider - hence user credentials are not shared with the Client App.

4) User redirected back to Client App with Verifier Token

When the user is redirected to the Client App, the Request Token and a ‘Verifier Token’ are appended to the URL. The Request Token allows the Client App to identify the user that initiated the authorization process.

The Verifier Token is a random value generated by the Service Provider for each successful user authorization. It is known only by the Service Provider and the Client App and sent in subsequent Access Token requests (step 5) as an additional security measure in case the Request Token details have been compromised.

5) The Client App requests a user-specific Access Token

The request consists of:

1. The initial Request Token (to identify the current auth process)
2. The Verifier Token (to prove user access was granted)
3. The Consumer Key (to confirm the Client App making the request)
4. A signature created from the request parameters, the Consumer Secret and the Request Token Secret, along with the name of the signature algorithm used.

The Service Provider, knowing the Consumer Secret and Request Token Secret, verifies the signature. A unique and unguessable Access Token and an Access Token Secret are sent back to the app server.

6) Access Token and Access Token Secret then verify the authenticity of subsequent user-sensitive requests

The Access Token identifies the user along with the specific permissions granted to the client-app, and included in subsequent user resource requests to verify the client app has been authorized to make such requests.

As an additional verification measure, each request includes a signature based on the Consumer Secret and Access Token Secret, with the signature method used. Given the Service Provider knows the Consumer Secret and Access Token Secret, it can verify the signature ensuring each client request is authentic.

The signature verification prevents against interception (‘man-in-the-middle’ attacks) and subsequent user impersonation, since the Consumer Secret is never sent in any HTTP request/response in the OAuth 1.0 process, and the Access Token Secret is sent only once to the Client App, to proving the authenticity of future requests.

OAuth 1.0 Limitations

Find OAuth 1.0 confusing? Me too.

Even this outline of the OAuth 1.0 flow hasn’t covered the explicit implementation details. The convoluted process of providing secure user authorization is one of a number of OAuth 1.0 drawbacks. Here are a few more:

1. Complexity

The number of requests, keys, secrets, signatures, and amount of cryptography involved means a developer implementation ‘from scratch’, which doesn’t introduce vulnerabilities, can be very difficult. Even apps using established OAuth 1.0 libraries may still have vulnerabilities if misconfigured.

1. Secret security

OAuth 1.0 is mainly designed for server-based Client Apps, as the secrets needed to certify requests must be stored securely. While these secrets can be stored in the browser or on mobile devices, these storage locations are at a greater risk of being compromised, making OAuth 1.0 less suitable for Single Page Applications and native apps.

1. Scalability adjustments

Secrets specific to each authorization process, such as a user’s Access Token, need to be stored at both the Service Provider’s server and the Client App’s server - if either needs horizontal scaling, they also need to ensure all server nodes have access consistent data.

The limitations of OAuth 1.0 as an authorization framework lead to the development of OAuth 2.0, which subsequently gained widespread adoption.

OAuth 2.0 is covered in detail in the next post.

Web Security series

1) Common Browser Security Concepts 2) Cookies - A guide for developers 3) HTTP Basic Access Authentication 4) Maintaining Authentication State with Session Cookies 5) JWT Essentials 6) OAuth 1.0 7) OAuth 2.0 Overview 8) OAuth 2.0 Authorization Code Flow 9) OAuth 2.0 Implicit Flow 10) OAuth 2.0 Authorization Code Flow with PKCE 11) OAuth 2.0 Device Authorization Flow 12) OpenID Connect - OAuth 2.0 with Authentication