OAuth 2.0 Document translation (chapter I)

OAuth 2.0 Authorization Framework

Profile

The OAuth 2.0 authorization framework enables third-party applications to obtain limited HTTP services and also represents the user (the resource owner) who is authorized by planning an approved communication between the user and the HTTP service, or by running a third-party application on behalf of itself. This documentation replaces the outdated OAuth 1.0 protocol described in RFC 5849.

The status of this memorandum

This is an Internet standard tracking document.

This document is the work of the IETF (Internet Engineering Task Force: Internet Engineering Task Group). Represents the consensus of the IETF team. Accepted public scrutiny and was approved for release by IESG (Internet Engineering Steering Group: Internet Engineering Steering Group). Internet standards more detailed information can be obtained in section 2 of RFC 5741.

The first chapter: Introduction

In the traditional Client-server authentication model, Client uses resource owner's certificate authentication on the server side and then requests protected resource. To enable third-party apps to access protected Resource,resource owner shares its credentials with a third party, but this also has some drawbacks:

1. Third-party applications are required to store resource owner's certificates for future use, (certificates) are usually plaintext passwords.

2. The server is required to support password authorization regardless of the inherent security flaws in the password.

3. Third-party applications get too many user rights, making resource owner unable to limit the duration (certificate validity time) or access a limited subset of resources.

4.resource owner has no way to revoke access to an app by changing the password of the user account, but this also revokes access to other apps. (probably means that third-party accounts and passwords are common to all third-party applications, and it is not possible to restrict only one application)

5. Any third-party application is cracked, and the user's password and associated data are compromised.

OAuth 2.0 solves this problem by introducing the authorization layer and separating the client role from the user. In OAuth 2.0, the client requests access to resources that are controlled by the source owner and sent to the resource server. And this assigns a series of different certificates.

Instead of using resource owner's certificate access protected resources,client Gets an access token (task token)-a string that indicates the specific scope, life cycle, and other access properties. Access token is assigned by authorization server to a third-party client by resource owner consent. Client uses access token to access resources managed by resource server.

For example, an end user (resource owner) can authorize a printing service (client) to access protected photo stored on the photo sharing service (resource server). Instead of having his username and password tell the printing service. Instead, he can authenticate with a server that is trusted by the photo sharing service (authorization server), and the server assigns a specific authorization certificate (access token) to the printing service.

This document is designed for use with HTTP. ([RFC2616]). The use of the OAuth protocol temporarily does not support protocols other than the HTTP protocol.

The OAuth 1.0 protocol, published as a report document, is a result of a small and special team effort. This standard tracking documentation is based on the experience of the OAuth 1 deployment as well as additional use cases and extensibility requirements stemming from the broader IETF (Internet Engineering Task Force: Internet Engineering Task Team).

The OAuth 2.0 protocol is not backwards compatible with the OAuth 1.0 protocol. These two versions coexist on the Internet, and implementations may choose to support both. However, this document is intended to indicate that the new implementation supports OAuth 2.0, while OAuth 1.0 only supports implementations that already exist. OAuth 2.0 and OAuth 1.0 are rarely the same in specific implementation details. Users who are familiar with the OAuth 1.0 implementation do not have to assume that OAuth 2.0 is its structure and details.

OAuth 2.0 Document translation (chapter I)