Specification Structure

The OAuth specification consists of two parts. The first part defines a redirection-based browser process for end-users to authorize client access to their resources. This is done by having the users authenticate directly with the server, instructing the server to provision tokens to the client for use with the authentication method.

The second part defines a method for making authenticated HTTP requests using two sets of credentials, one identifying the client making the request, and the other identifying the resource owner on whose behalf the request is being made.

The following is an outline of the OAuth 1.0 protocol specification:

  1. Introduction – the introduction provides a quick overview of the specification and its objectives. The terminology sub-section defines the terms used and their relation to the HTTP specification (this guide provides a more detailed description). The example sub-section provides a full walk-through, describing a typical use case of a user sharing photos on one site and looking to print them on another.
  2. Redirection-Based Authorization – the authorization flow is what most people think of when they talk about OAuth. It is the process in which the user is redirected to the server to provide access. This section describes the three steps used to request and grant access: Obtaining Temporary Credentials, Requesting Resource Owner Authorization, and Obtaining Token Credentials.
  3. Authenticated Requests – In order for the client to obtain a set of token credentials and use it to access protected resources, the client must make authenticated HTTP requests. This section describes how the client makes such requests, how the server verifies them, and the various steps and cryptographic options available. Most of this section is dedicated to the construction of the signature base string, the normalized version of the request used for signing.
  4. Security Considerations – this often-overlooked section is a must-read for any developer writing client or server code. It provides a comprehensive (but never complete) list of issues which can greatly impact the security properties of any given implementation. Developers should read this list before starting any OAuth related project, and read it at least once more when they are done to review.

Another section worth mentioning is Appendix A which lists the differences from the community edition. While the RFC edition is the same as the OAuth Core 1.0 Revision A specification, some of its clarifications and errata require code changes on both the client and server sides. Developers working on existing implementations should pay close attentions to the variations described.

Continue to Protocol Workflow

3 thoughts on “Specification Structure

Comments are closed.