RFC 6749

RFC 6749. Published in October 2012 by the Internet Engineering Task Force, this document defines the OAuth 2.0 authorization framework, a core protocol enabling secure, delegated access to protected resources. It was authored by Dick Hardt and Michael B. Jones, superseding the earlier RFC 5849 for OAuth 1.0. The framework provides a method for clients to obtain limited access to a Hypertext Transfer Protocol server on behalf of a resource owner, without sharing the owner's credentials.

● Overview

RFC 6749 establishes a standardized architecture for authorization, separating the roles of the client application, the resource owner, and the authorization server. It is designed to work specifically over HTTP and is widely implemented by major technology platforms like Google, Facebook, and Microsoft. The protocol's primary goal is to simplify client development while providing specific authorization flows for different types of applications, such as web applications, user-agent-based apps, and native applications. This flexibility has made it a foundational standard for modern API security and single sign-on systems across the World Wide Web.

● OAuth 2.0 Authorization Framework

The framework detailed in the document is built upon several key abstractions and roles. The central interaction involves a client requesting access to resources controlled by the resource owner and hosted by a resource server. To gain access, the client must obtain an authorization grant, which is a credential representing the owner's consent, and then exchange it for an access token from the authorization server. This token-based approach, distinct from the cryptographic signature method of OAuth 1.0, delegates complex security to the Transport Layer Security protocol. The specification was developed within the IETF's OAuth Working Group and is complemented by related standards like RFC 6750 for token usage.

● Authorization Grants

The specification defines four primary grant types to accommodate different client capabilities and deployment scenarios. The authorization code grant is used by web server applications and is considered the most secure, as it avoids exposing tokens to the user agent. The implicit grant is a simplified flow optimized for clients implemented in a browser using a scripting language like JavaScript. The resource owner password credentials grant is used only in high-trust situations, such as applications developed by the service itself. Finally, the client credentials grant is appropriate for machine-to-machine authentication where a specific user context is not required.

● Protocol Endpoints

RFC 6749 standardizes two critical HTTP endpoints that participants in the flow must implement. The authorization endpoint is where the resource owner authenticates and grants or denies the client's access request, often resulting in a redirect containing an authorization code. The token endpoint is used by the client to exchange an authorization grant for an access token and is the only location where client authentication is mandatory. These endpoints are hosted by the authorization server, and their precise URIs are typically discovered through service documentation or metadata formats like those defined in OpenID Connect Discovery.

● Security Considerations

An extensive section of the document is devoted to analyzing threats and prescribing countermeasures, acknowledging that security largely depends on correct implementation and the use of Transport Layer Security. It warns of risks such as phishing, redirect URI manipulation, cross-site request forgery in the authorization flow, and improper token storage. The specification explicitly advises against using the implicit grant for sensitive data and emphasizes that access tokens must be treated as opaque strings by clients. These considerations have been further elaborated in subsequent IETF publications like RFC 6819, the OAuth 2.0 Threat Model and Security Considerations.

● Relationship to OAuth 1.0

RFC 6749 obsoletes RFC 5849, introducing significant architectural departures from OAuth 1.0. While OAuth 1.0 required clients to cryptographically sign each request, OAuth 2.0 relies on Transport Layer Security to secure the connection and treats the access token as a bearer credential. This shift simplified implementation and integration, particularly for developers building applications for mobile devices and JavaScript-based clients. However, this change also transferred more security responsibility to developers and server operators, a trade-off that has been the subject of ongoing discussion within the Internet Engineering Task Force and the wider security community.

Category:Internet standards Category:Computer security Category:Identity management