Internet Engineering Task Force (IETF) E. Hammer-Lahav, Ed.
Request for Comments: 5849 April 2010
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Hammer-Lahav, Ed.
Request for Comments: 5849 April 2010
Category: Informational
ISSN: 2070-1721
The OAuth 1.0 Protocol
OAuth 1.0协议
Abstract
摘要
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
OAuth为客户端提供了一种代表资源所有者（例如不同的客户端或最终用户）访问服务器资源的方法。它还为最终用户提供了一个过程，使用用户代理重定向授权第三方访问其服务器资源，而无需共享其凭据（通常是用户名和密码对）。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5849.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5849.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Example ....................................................5
1.3. Notational Conventions .....................................7
2. Redirection-Based Authorization .................................8
2.1. Temporary Credentials ......................................9
2.2. Resource Owner Authorization ..............................10
2.3. Token Credentials .........................................12
3. Authenticated Requests .........................................14
3.1. Making Requests ...........................................14
3.2. Verifying Requests ........................................16
3.3. Nonce and Timestamp .......................................17
3.4. Signature .................................................18
3.4.1. Signature Base String ..............................18
3.4.2. HMAC-SHA1 ..........................................25
3.4.3. RSA-SHA1 ...........................................25
3.4.4. PLAINTEXT ..........................................26
3.5. Parameter Transmission ....................................26
3.5.1. Authorization Header ...............................27
3.5.2. Form-Encoded Body ..................................28
3.5.3. Request URI Query ..................................28
3.6. Percent Encoding ..........................................29
4. Security Considerations ........................................29
4.1. RSA-SHA1 Signature Method .................................29
4.2. Confidentiality of Requests ...............................30
4.3. Spoofing by Counterfeit Servers ...........................30
4.4. Proxying and Caching of Authenticated Content .............30
4.5. Plaintext Storage of Credentials ..........................30
4.6. Secrecy of the Client Credentials .........................31
4.7. Phishing Attacks ..........................................31
4.8. Scoping of Access Requests ................................31
4.9. Entropy of Secrets ........................................32
4.10. Denial-of-Service / Resource-Exhaustion Attacks ..........32
4.11. SHA-1 Cryptographic Attacks ..............................33
4.12. Signature Base String Limitations ........................33
4.13. Cross-Site Request Forgery (CSRF) ........................33
4.14. User Interface Redress ...................................34
4.15. Automatic Processing of Repeat Authorizations ............34
5. Acknowledgments ................................................35
Appendix A. Differences from the Community Edition ...............36
6. References .....................................................37
6.1. Normative References ......................................37
6.2. Informative References ....................................38
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Example ....................................................5
1.3. Notational Conventions .....................................7
2. Redirection-Based Authorization .................................8
2.1. Temporary Credentials ......................................9
2.2. Resource Owner Authorization ..............................10
2.3. Token Credentials .........................................12
3. Authenticated Requests .........................................14
3.1. Making Requests ...........................................14
3.2. Verifying Requests ........................................16
3.3. Nonce and Timestamp .......................................17
3.4. Signature .................................................18
3.4.1. Signature Base String ..............................18
3.4.2. HMAC-SHA1 ..........................................25
3.4.3. RSA-SHA1 ...........................................25
3.4.4. PLAINTEXT ..........................................26
3.5. Parameter Transmission ....................................26
3.5.1. Authorization Header ...............................27
3.5.2. Form-Encoded Body ..................................28
3.5.3. Request URI Query ..................................28
3.6. Percent Encoding ..........................................29
4. Security Considerations ........................................29
4.1. RSA-SHA1 Signature Method .................................29
4.2. Confidentiality of Requests ...............................30
4.3. Spoofing by Counterfeit Servers ...........................30
4.4. Proxying and Caching of Authenticated Content .............30
4.5. Plaintext Storage of Credentials ..........................30
4.6. Secrecy of the Client Credentials .........................31
4.7. Phishing Attacks ..........................................31
4.8. Scoping of Access Requests ................................31
4.9. Entropy of Secrets ........................................32
4.10. Denial-of-Service / Resource-Exhaustion Attacks ..........32
4.11. SHA-1 Cryptographic Attacks ..............................33
4.12. Signature Base String Limitations ........................33
4.13. Cross-Site Request Forgery (CSRF) ........................33
4.14. User Interface Redress ...................................34
4.15. Automatic Processing of Repeat Authorizations ............34
5. Acknowledgments ................................................35
Appendix A. Differences from the Community Edition ...............36
6. References .....................................................37
6.1. Normative References ......................................37
6.2. Informative References ....................................38
The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007, and revised in June 2009 (Revision A) as published at <http://oauth.net/core/1.0a>.
OAuth协议最初是由来自各种网站和其他Internet服务的web开发人员组成的一个小社区创建的，他们希望解决授权访问受保护资源的常见问题。由此产生的OAuth协议于2007年10月稳定在1.0版，并于2009年6月修订（A版），发布于<http://oauth.net/core/1.0a>.
This specification provides an informational documentation of OAuth Core 1.0 Revision A, addresses several errata reported since that time, and makes numerous editorial clarifications. While this specification is not an item of the IETF's OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track, it has been transferred to the IETF for change control by authors of the original work.
本规范提供了OAuth Core 1.0版本A的信息性文档，解决了自那时以来报告的几个勘误表，并进行了大量编辑澄清。虽然本规范不是IETF的OAuth工作组的一个项目，在编写本规范时，该工作组正在开发适合在标准轨道上发布的OAuth版本，但已将其转交给IETF，由原著作者进行变更控制。
In the traditional client-server authentication model, the client uses its credentials to access its resources hosted by the server. With the increasing use of distributed web services and cloud computing, third-party applications require access to these server-hosted resources.
在传统的客户机-服务器身份验证模型中，客户机使用其凭据访问服务器托管的资源。随着分布式web服务和云计算的日益使用，第三方应用程序需要访问这些服务器托管的资源。
OAuth introduces a third role to the traditional client-server authentication model: the resource owner. In the OAuth model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner, but hosted by the server. In addition, OAuth allows the server to verify not only the resource owner authorization, but also the identity of the client making the request.
OAuth为传统的客户机-服务器身份验证模型引入了第三个角色：资源所有者。在OAuth模型中，客户机（不是资源所有者，而是代表它）请求访问由资源所有者控制但由服务器托管的资源。此外，OAuth允许服务器不仅验证资源所有者授权，还验证发出请求的客户机的身份。
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.
OAuth为客户端提供了一种代表资源所有者（例如不同的客户端或最终用户）访问服务器资源的方法。它还为最终用户提供了一个过程，使用用户代理重定向授权第三方访问其服务器资源，而无需共享其凭据（通常是用户名和密码对）。
For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service. Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.
例如，web用户（资源所有者）可以授予打印服务（客户端）访问存储在照片共享服务（服务器）中的她的私人照片的权限，而无需与打印服务共享她的用户名和密码。相反，她直接通过照片共享服务进行身份验证，该服务会发布打印服务特定于授权的凭据。
In order for the client to access resources, it first has to obtain permission from the resource owner. This permission is expressed in the form of a token and matching shared-secret. The purpose of the token is to make it unnecessary for the resource owner to share its credentials with the client. Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and revoked independently.
为了让客户端访问资源，它首先必须获得资源所有者的权限。此权限以令牌和匹配的共享密钥的形式表示。令牌的目的是使资源所有者不必与客户端共享其凭据。与资源所有者凭据不同，令牌可以在有限的范围和有限的生存期内发出，并且可以独立撤销。
This specification consists of two parts. The first part defines a redirection-based user-agent process for end-users to authorize client access to their resources, by authenticating directly with the server and provisioning tokens to the client for use with the authentication method. The second part defines a method for making authenticated HTTP [RFC2616] requests using two sets of credentials, one identifying the client making the request, and a second identifying the resource owner on whose behalf the request is being made.
本规范由两部分组成。第一部分定义了一个基于重定向的用户代理流程，最终用户通过直接使用服务器进行身份验证，并向客户端提供令牌以与身份验证方法一起使用，从而授权客户端访问其资源。第二部分定义了一种使用两组凭证发出经过身份验证的HTTP[RFC2616]请求的方法，一组凭证标识发出请求的客户端，另一组凭证标识发出请求的资源所有者。
The use of OAuth with any transport protocol other than [RFC2616] is undefined.
OAuth与[RFC2616]以外的任何传输协议的使用尚未定义。
client An HTTP client (per [RFC2616]) capable of making OAuth-authenticated requests (Section 3).
客户端—能够发出OAuth认证请求的HTTP客户端（根据[RFC2616]）（第3节）。
server An HTTP server (per [RFC2616]) capable of accepting OAuth-authenticated requests (Section 3).
服务器能够接受OAuth认证请求的HTTP服务器（根据[RFC2616]）（第3节）。
protected resource An access-restricted resource that can be obtained from the server using an OAuth-authenticated request (Section 3).
受保护资源可使用OAuth认证请求从服务器获得的访问受限资源（第3节）。
resource owner An entity capable of accessing and controlling protected resources by using credentials to authenticate with the server.
资源所有者能够通过使用凭据向服务器进行身份验证来访问和控制受保护资源的实体。
credentials Credentials are a pair of a unique identifier and a matching shared secret. OAuth defines three classes of credentials: client, temporary, and token, used to identify and authenticate the client making the request, the authorization request, and the access grant, respectively.
凭据凭据是一对唯一标识符和匹配的共享机密。OAuth定义了三类凭据：客户端、临时和令牌，分别用于识别和验证发出请求的客户端、授权请求和访问授权。
token A unique identifier issued by the server and used by the client to associate authenticated requests with the resource owner whose authorization is requested or has been obtained by the client. Tokens have a matching shared-secret that is used by the client to establish its ownership of the token, and its authority to represent the resource owner.
令牌服务器发出的唯一标识符，客户端使用该标识符将经过身份验证的请求与客户端请求或已获得授权的资源所有者相关联。令牌有一个匹配的共享密钥，客户端使用该密钥来确定令牌的所有权，以及表示资源所有者的权限。
The original community specification used a somewhat different terminology that maps to this specifications as follows (original community terms provided on left):
原始社区规范使用了与本规范相对应的不同术语，如下所示（左侧提供了原始社区术语）：
Consumer: client
消费者：客户
Service Provider: server
服务提供者：服务器
User: resource owner
用户：资源所有者
Consumer Key and Secret: client credentials
使用者密钥和机密：客户端凭据
Request Token and Secret: temporary credentials
请求令牌和机密：临时凭据
Access Token and Secret: token credentials
访问令牌和密码：令牌凭据
Jane (resource owner) has recently uploaded some private vacation photos (protected resources) to her photo sharing site 'photos.example.net' (server). She would like to use the 'printer.example.com' website (client) to print one of these photos. Typically, Jane signs into 'photos.example.net' using her username and password.
Jane（资源所有者）最近将一些私人度假照片（受保护的资源）上传到她的照片共享网站“photos.example.net”（服务器）。她想使用“printer.example.com”网站（客户端）打印其中一张照片。通常，Jane会使用用户名和密码登录“photos.example.net”。
However, Jane does not wish to share her username and password with the 'printer.example.com' website, which needs to access the photo in order to print it. In order to provide its users with better service, 'printer.example.com' has signed up for a set of 'photos.example.net' client credentials ahead of time:
但是，Jane不希望与“printer.example.com”网站共享她的用户名和密码，该网站需要访问照片才能打印照片。为了向用户提供更好的服务，“printer.example.com”提前注册了一组“photos.example.net”客户端凭据：
Client Identifier dpf43f3p2l4k3l03
客户端标识符dpf43f3p2l4k3l03
Client Shared-Secret: kd94hf93k423kf44
客户端共享密钥：kd94hf93k423kf44
The 'printer.example.com' website has also configured its application to use the protocol endpoints listed in the 'photos.example.net' API documentation, which use the "HMAC-SHA1" signature method:
“printer.example.com”网站还将其应用程序配置为使用“photos.example.net”API文档中列出的协议端点，该文档使用“HMAC-SHA1”签名方法：
Temporary Credential Request
https://photos.example.net/initiate
Temporary Credential Request
https://photos.example.net/initiate
Resource Owner Authorization URI:
https://photos.example.net/authorize
Resource Owner Authorization URI:
https://photos.example.net/authorize
Token Request URI:
https://photos.example.net/token
Token Request URI:
https://photos.example.net/token
Before 'printer.example.com' can ask Jane to grant it access to the photos, it must first establish a set of temporary credentials with 'photos.example.net' to identify the delegation request. To do so, the client sends the following HTTPS [RFC2818] request to the server:
在“printer.example.com”要求Jane授予其对照片的访问权限之前，它必须首先使用“photos.example.net”建立一组临时凭据，以标识委派请求。为此，客户端向服务器发送以下HTTPS[RFC2818]请求：
POST /initiate HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
POST /initiate HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
The server validates the request and replies with a set of temporary credentials in the body of the HTTP response (line breaks are for display purposes only):
服务器验证请求并在HTTP响应主体中使用一组临时凭据进行响应（换行符仅用于显示目的）：
HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK内容类型：application/x-www-form-urlencoded
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03& oauth_callback_confirmed=true
oauth_令牌=hh5s93j4hdipola&oauth_令牌\u secret=hdhd0244k9j7ao03&oauth_回调\u确认=true
The client redirects Jane's user-agent to the server's Resource Owner Authorization endpoint to obtain Jane's approval for accessing her private photos:
客户端将Jane的用户代理重定向到服务器的资源所有者授权端点，以获得Jane对访问其私人照片的批准：
https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola
The server requests Jane to sign in using her username and password and if successful, asks her to approve granting 'printer.example.com' access to her private photos. Jane approves the request and her user-agent is redirected to the callback URI provided by the client in the previous request (line breaks are for display purposes only):
服务器请求Jane使用她的用户名和密码登录，如果成功，请她批准授予“printer.example.com”访问她的私人照片的权限。Jane批准该请求，并且她的用户代理被重定向到客户端在上一个请求中提供的回调URI（换行符仅用于显示目的）：
http://printer.example.com/ready?
oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
http://printer.example.com/ready?
oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884
The callback request informs the client that Jane completed the authorization process. The client then requests a set of token credentials using its temporary credentials (over a secure Transport Layer Security (TLS) channel):
回调请求通知客户端Jane已完成授权过程。然后，客户端使用其临时凭据（通过安全传输层安全（TLS）通道）请求一组令牌凭据：
POST /token HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="hh5s93j4hdidpola",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="walatlh",
oauth_verifier="hfdp7dh39dks9884",
oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
POST /token HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="hh5s93j4hdidpola",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="walatlh",
oauth_verifier="hfdp7dh39dks9884",
oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
The server validates the request and replies with a set of token credentials in the body of the HTTP response:
服务器验证请求并在HTTP响应主体中使用一组令牌凭据进行响应：
HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK内容类型：application/x-www-form-urlencoded
oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
With a set of token credentials, the client is now ready to request the private photo:
通过一组令牌凭据，客户端现在可以请求私人照片：
GET /photos?file=vacation.jpg&size=original HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131202",
oauth_nonce="chapoH",
oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
GET /photos?file=vacation.jpg&size=original HTTP/1.1
Host: photos.example.net
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131202",
oauth_nonce="chapoH",
oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
The 'photos.example.net' server validates the request and responds with the requested photo. 'printer.example.com' is able to continue accessing Jane's private photos using the same set of token credentials for the duration of Jane's authorization, or until Jane revokes access.
“photos.example.net”服务器验证请求并使用请求的照片进行响应printer.example.com’能够在Jane授权期间或直到Jane撤销访问之前，继续使用同一组令牌凭据访问Jane的私人照片。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
OAuth uses tokens to represent the authorization granted to the client by the resource owner. Typically, token credentials are issued by the server at the resource owner's request, after authenticating the resource owner's identity (usually using a username and password).
OAuth使用令牌表示资源所有者授予客户机的授权。通常，在验证资源所有者的身份（通常使用用户名和密码）后，服务器应资源所有者的请求颁发令牌凭据。
There are many ways in which a server can facilitate the provisioning of token credentials. This section defines one such way, using HTTP redirections and the resource owner's user-agent. This redirection-based authorization method includes three steps:
服务器可以通过多种方式促进令牌凭据的提供。本节使用HTTP重定向和资源所有者的用户代理定义了这样一种方法。此基于重定向的授权方法包括三个步骤：
1. The client obtains a set of temporary credentials from the server (in the form of an identifier and shared-secret). The temporary credentials are used to identify the access request throughout the authorization process.
1. 客户端从服务器获取一组临时凭据（以标识符和共享密钥的形式）。临时凭据用于在整个授权过程中标识访问请求。
2. The resource owner authorizes the server to grant the client's access request (identified by the temporary credentials).
2. 资源所有者授权服务器授予客户端的访问请求（由临时凭据标识）。
3. The client uses the temporary credentials to request a set of token credentials from the server, which will enable it to access the resource owner's protected resources.
3. 客户端使用临时凭据从服务器请求一组令牌凭据，这将使其能够访问资源所有者的受保护资源。
The server MUST revoke the temporary credentials after being used once to obtain the token credentials. It is RECOMMENDED that the temporary credentials have a limited lifetime. Servers SHOULD enable resource owners to revoke token credentials after they have been issued to clients.
服务器必须在使用一次临时凭据以获取令牌凭据后撤消该凭据。建议临时凭据具有有限的生存期。服务器应使资源所有者能够在令牌凭据被颁发给客户端后撤消令牌凭据。
In order for the client to perform these steps, the server needs to advertise the URIs of the following three endpoints:
为了让客户端执行这些步骤，服务器需要公布以下三个端点的URI：
Temporary Credential Request The endpoint used by the client to obtain a set of temporary credentials as described in Section 2.1.
临时凭证请求客户端用于获取一组临时凭证的端点，如第2.1节所述。
Resource Owner Authorization The endpoint to which the resource owner is redirected to grant authorization as described in Section 2.2.
资源所有者授权资源所有者被重定向到的端点，如第2.2节所述授予授权。
Token Request The endpoint used by the client to request a set of token credentials using the set of temporary credentials as described in Section 2.3.
令牌请求客户端使用第2.3节所述的临时凭据集请求令牌凭据集的端点。
The three URIs advertised by the server MAY include a query component as defined by [RFC3986], Section 3, but if present, the query MUST NOT contain any parameters beginning with the "oauth_" prefix, to avoid conflicts with the protocol parameters added to the URIs when used.
服务器公布的三个URI可能包括[RFC3986]第3节定义的查询组件，但如果存在，则查询不得包含任何以“oauth_”前缀开头的参数，以避免在使用时与添加到URI的协议参数发生冲突。
The methods in which the server advertises and documents its three endpoints are beyond the scope of this specification. Clients should avoid making assumptions about the size of tokens and other server-generated values, which are left undefined by this specification. In addition, protocol parameters MAY include values that require encoding when transmitted. Clients and servers should not make assumptions about the possible range of their values.
服务器播发和记录其三个端点的方法超出了本规范的范围。客户机应该避免对令牌和其他服务器生成的值的大小进行假设，这是本规范未定义的。此外，协议参数可包括传输时需要编码的值。客户端和服务器不应该对其值的可能范围进行假设。
The client obtains a set of temporary credentials from the server by making an authenticated (Section 3) HTTP "POST" request to the Temporary Credential Request endpoint (unless the server advertises another HTTP request method for the client to use). The client constructs a request URI by adding the following REQUIRED parameter to the request (in addition to the other protocol parameters, using the same parameter transmission method):
客户端通过向临时凭据请求端点发出经过身份验证（第3节）的HTTP“POST”请求，从服务器获取一组临时凭据（除非服务器播发另一个HTTP请求方法供客户端使用）。客户端通过向请求添加以下必需参数（除了其他协议参数外，使用相同的参数传输方法）来构造请求URI：
oauth_callback: An absolute URI back to which the server will redirect the resource owner when the Resource Owner Authorization step (Section 2.2) is completed. If the client is unable to receive callbacks or a callback URI has been established via other means, the parameter value MUST be set to "oob" (case sensitive), to indicate an out-of-band configuration.
oauth_回调：当资源所有者授权步骤（第2.2节）完成时，服务器将资源所有者重定向回的绝对URI。如果客户端无法接收回调或通过其他方式建立了回调URI，则必须将参数值设置为“oob”（区分大小写），以指示带外配置。
Servers MAY specify additional parameters.
服务器可以指定其他参数。
When making the request, the client authenticates using only the client credentials. The client MAY omit the empty "oauth_token" protocol parameter from the request and MUST use the empty string as the token secret value.
发出请求时，客户端仅使用客户端凭据进行身份验证。客户端可以从请求中省略空的“oauth_token”协议参数，并且必须使用空字符串作为令牌秘密值。
Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanisms such as TLS or Secure Socket Layer (SSL) (or a secure channel with equivalent protections).
由于请求导致在HTTP响应中传输纯文本凭据，因此服务器必须要求使用传输层机制，如TLS或安全套接字层（SSL）（或具有等效保护的安全通道）。
For example, the client makes the following HTTPS request:
例如，客户端发出以下HTTPS请求：
POST /request_temp_credentials HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_signature_method="PLAINTEXT",
oauth_callback="http%3A%2F%2Fclient.example.net%2Fcb%3Fx%3D1",
oauth_signature="ja893SD9%26"
POST /request_temp_credentials HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_signature_method="PLAINTEXT",
oauth_callback="http%3A%2F%2Fclient.example.net%2Fcb%3Fx%3D1",
oauth_signature="ja893SD9%26"
The server MUST verify (Section 3.2) the request and if valid, respond back to the client with a set of temporary credentials (in the form of an identifier and shared-secret). The temporary credentials are included in the HTTP response body using the "application/x-www-form-urlencoded" content type as defined by [W3C.REC-html40-19980424] with a 200 status code (OK).
服务器必须验证（第3.2节）请求，如果有效，则使用一组临时凭据（以标识符和共享机密的形式）向客户端作出响应。使用[W3C.REC-html40-19980424]定义的“application/x-www-form-urlencoded”内容类型（状态代码为200）将临时凭证包含在HTTP响应正文中。
The response contains the following REQUIRED parameters:
响应包含以下必需参数：
oauth_token The temporary credentials identifier.
oauth_标记临时凭据标识符。
oauth_token_secret The temporary credentials shared-secret.
oauth_令牌_secret临时凭据共享密钥。
oauth_callback_confirmed MUST be present and set to "true". The parameter is used to differentiate from previous versions of the protocol.
oauth_callback_confirm必须存在并设置为“true”。该参数用于区分协议的早期版本。
Note that even though the parameter names include the term 'token', these credentials are not token credentials, but are used in the next two steps in a similar manner to token credentials.
请注意，尽管参数名称包括术语“令牌”，但这些凭据不是令牌凭据，而是在接下来的两个步骤中以与令牌凭据类似的方式使用。
For example (line breaks are for display purposes only):
例如（换行符仅用于显示目的）：
HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK内容类型：application/x-www-form-urlencoded
oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b& oauth_callback_confirmed=true
oauth_token=hdk48Djdsa&oauth_token_secret=xyz4992k83j47x0b&oauth_callback_confirm=true
Before the client requests a set of token credentials from the server, it MUST send the user to the server to authorize the request. The client constructs a request URI by adding the following REQUIRED query parameter to the Resource Owner Authorization endpoint URI:
在客户端从服务器请求一组令牌凭据之前，它必须将用户发送到服务器以授权该请求。客户端通过向资源所有者授权端点URI添加以下必需的查询参数来构造请求URI：
oauth_token The temporary credentials identifier obtained in Section 2.1 in the "oauth_token" parameter. Servers MAY declare this parameter as OPTIONAL, in which case they MUST provide a way for the resource owner to indicate the identifier through other means.
oauth_令牌在“oauth_令牌”参数的第2.1节中获得的临时凭证标识符。服务器可以将此参数声明为可选参数，在这种情况下，它们必须为资源所有者提供一种通过其他方式指示标识符的方法。
Servers MAY specify additional parameters.
服务器可以指定其他参数。
The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the resource owner's user-agent. The request MUST use the HTTP "GET" method.
客户端使用HTTP重定向响应或通过资源所有者的用户代理提供的其他方式将资源所有者定向到构造的URI。请求必须使用HTTP“GET”方法。
For example, the client redirects the resource owner's user-agent to make the following HTTPS request:
例如，客户端重定向资源所有者的用户代理以发出以下HTTPS请求：
GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1
Host: server.example.com
GET /authorize_access?oauth_token=hdk48Djdsa HTTP/1.1
Host: server.example.com
The way in which the server handles the authorization request, including whether it uses a secure channel such as TLS/SSL is beyond the scope of this specification. However, the server MUST first verify the identity of the resource owner.
服务器处理授权请求的方式，包括是否使用安全通道（如TLS/SSL），超出了本规范的范围。但是，服务器必须首先验证资源所有者的身份。
When asking the resource owner to authorize the requested access, the server SHOULD present to the resource owner information about the client requesting access based on the association of the temporary credentials with the client identity. When displaying any such information, the server SHOULD indicate if the information has been verified.
当请求资源所有者授权请求的访问时，服务器应根据临时凭据与客户端标识的关联，向资源所有者提供有关请求访问的客户端的信息。显示任何此类信息时，服务器应指示信息是否已验证。
After receiving an authorization decision from the resource owner, the server redirects the resource owner to the callback URI if one was provided in the "oauth_callback" parameter or by other means.
在收到资源所有者的授权决定后，如果“oauth_callback”参数中提供了回调URI，服务器会将资源所有者重定向到回调URI，或者通过其他方式。
To make sure that the resource owner granting access is the same resource owner returning back to the client to complete the process, the server MUST generate a verification code: an unguessable value passed to the client via the resource owner and REQUIRED to complete the process. The server constructs the request URI by adding the following REQUIRED parameters to the callback URI query component:
要确保授予访问权限的资源所有者是返回到客户端以完成流程的同一资源所有者，服务器必须生成一个验证代码：一个通过资源所有者传递给客户端并完成流程所需的不可用值。服务器通过向回调URI查询组件添加以下必需参数来构造请求URI：
oauth_token The temporary credentials identifier received from the client.
oauth_令牌从客户端接收的临时凭据标识符。
oauth_verifier The verification code.
oauth_验证器验证代码。
If the callback URI already includes a query component, the server MUST append the OAuth parameters to the end of the existing query.
如果回调URI已经包含查询组件，则服务器必须将OAuth参数附加到现有查询的末尾。
For example, the server redirects the resource owner's user-agent to make the following HTTP request:
例如，服务器重定向资源所有者的用户代理以发出以下HTTP请求：
GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1
Host: client.example.net
GET /cb?x=1&oauth_token=hdk48Djdsa&oauth_verifier=473f82d3 HTTP/1.1
Host: client.example.net
If the client did not provide a callback URI, the server SHOULD display the value of the verification code, and instruct the resource owner to manually inform the client that authorization is completed. If the server knows a client to be running on a limited device, it SHOULD ensure that the verifier value is suitable for manual entry.
如果客户端未提供回调URI，服务器应显示验证代码的值，并指示资源所有者手动通知客户端授权已完成。如果服务器知道客户端正在有限的设备上运行，则应确保验证器值适合手动输入。
The client obtains a set of token credentials from the server by making an authenticated (Section 3) HTTP "POST" request to the Token Request endpoint (unless the server advertises another HTTP request method for the client to use). The client constructs a request URI by adding the following REQUIRED parameter to the request (in addition to the other protocol parameters, using the same parameter transmission method):
客户端通过向令牌请求端点发出经过身份验证（第3节）的HTTP“POST”请求，从服务器获取一组令牌凭据（除非服务器播发另一个HTTP请求方法供客户端使用）。客户端通过向请求添加以下必需参数（除了其他协议参数外，使用相同的参数传输方法）来构造请求URI：
oauth_verifier The verification code received from the server in the previous step.
oauth_验证器在上一步中从服务器接收的验证代码。
When making the request, the client authenticates using the client credentials as well as the temporary credentials. The temporary credentials are used as a substitute for token credentials in the authenticated request and transmitted using the "oauth_token" parameter.
发出请求时，客户端使用客户端凭据以及临时凭据进行身份验证。临时凭证用作身份验证请求中令牌凭证的替代品，并使用“oauth_token”参数进行传输。
Since the request results in the transmission of plain text credentials in the HTTP response, the server MUST require the use of a transport-layer mechanism such as TLS or SSL (or a secure channel with equivalent protections).
由于请求导致在HTTP响应中传输纯文本凭据，因此服务器必须要求使用传输层机制，如TLS或SSL（或具有同等保护的安全通道）。
For example, the client makes the following HTTPS request:
例如，客户端发出以下HTTPS请求：
POST /request_token HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_token="hdk48Djdsa",
oauth_signature_method="PLAINTEXT",
oauth_verifier="473f82d3",
oauth_signature="ja893SD9%26xyz4992k83j47x0b"
POST /request_token HTTP/1.1
Host: server.example.com
Authorization: OAuth realm="Example",
oauth_consumer_key="jd83jd92dhsh93js",
oauth_token="hdk48Djdsa",
oauth_signature_method="PLAINTEXT",
oauth_verifier="473f82d3",
oauth_signature="ja893SD9%26xyz4992k83j47x0b"
The server MUST verify (Section 3.2) the validity of the request, ensure that the resource owner has authorized the provisioning of token credentials to the client, and ensure that the temporary credentials have not expired or been used before. The server MUST also verify the verification code received from the client. If the request is valid and authorized, the token credentials are included in the HTTP response body using the "application/x-www-form-urlencoded" content type as defined by [W3C.REC-html40-19980424] with a 200 status code (OK).
服务器必须验证（第3.2节）请求的有效性，确保资源所有者已授权向客户端提供令牌凭据，并确保临时凭据以前未过期或使用过。服务器还必须验证从客户端收到的验证代码。如果请求有效且经过授权，则令牌凭证将使用[W3C.REC-html40-19980424]定义的“application/x-www-form-URLCoded”内容类型（状态代码为200）包含在HTTP响应正文中。
The response contains the following REQUIRED parameters:
响应包含以下必需参数：
oauth_token The token identifier.
oauth_标记标记标识符。
oauth_token_secret The token shared-secret.
oauth_token_secret令牌共享密钥。
For example:
例如：
HTTP/1.1 200 OK Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK内容类型：application/x-www-form-urlencoded
oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk
oauth_token=j49ddk933skd9dks&oauth_token_secret=ll399dj47dskfjdk
The server must retain the scope, duration, and other attributes approved by the resource owner, and enforce these restrictions when receiving a client request made with the token credentials issued.
服务器必须保留资源所有者批准的范围、持续时间和其他属性，并在接收使用已颁发的令牌凭据发出的客户端请求时强制执行这些限制。
Once the client receives and stores the token credentials, it can proceed to access protected resources on behalf of the resource owner by making authenticated requests (Section 3) using the client credentials together with the token credentials received.
一旦客户端接收并存储令牌凭据，它就可以继续代表资源所有者访问受保护的资源，方法是使用客户端凭据和接收到的令牌凭据发出经过身份验证的请求（第3节）。
The HTTP authentication methods defined by [RFC2617] enable clients to make authenticated HTTP requests. Clients using these methods gain access to protected resources by using their credentials (typically, a username and password pair), which allow the server to verify their authenticity. Using these methods for delegation requires the client to assume the role of the resource owner.
[RFC2617]定义的HTTP身份验证方法允许客户端发出经过身份验证的HTTP请求。使用这些方法的客户端通过使用其凭据（通常是用户名和密码对）获得对受保护资源的访问权限，该凭据允许服务器验证其真实性。使用这些方法进行委派需要客户机承担资源所有者的角色。
OAuth provides a method designed to include two sets of credentials with each request, one to identify the client, and another to identify the resource owner. Before a client can make authenticated requests on behalf of the resource owner, it must obtain a token authorized by the resource owner. Section 2 provides one such method through which the client can obtain a token authorized by the resource owner.
OAuth提供了一种方法，用于在每个请求中包含两组凭据，一组用于标识客户端，另一组用于标识资源所有者。在客户端可以代表资源所有者发出经过身份验证的请求之前，它必须获得资源所有者授权的令牌。第2节提供了一种这样的方法，通过该方法，客户端可以获得由资源所有者授权的令牌。
The client credentials take the form of a unique identifier and an associated shared-secret or RSA key pair. Prior to making authenticated requests, the client establishes a set of credentials with the server. The process and requirements for provisioning these are outside the scope of this specification. Implementers are urged to consider the security ramifications of using client credentials, some of which are described in Section 4.6.
客户端凭据采用唯一标识符和关联的共享密钥或RSA密钥对的形式。在发出经过身份验证的请求之前，客户端将与服务器建立一组凭据。提供这些资源的过程和要求不在本规范的范围内。敦促执行者考虑使用客户端凭证的安全后果，其中一些在第4.6节中描述。
Making authenticated requests requires prior knowledge of the server's configuration. OAuth includes multiple methods for transmitting protocol parameters with requests (Section 3.5), as well as multiple methods for the client to prove its rightful ownership of the credentials used (Section 3.4). The way in which clients discover the required configuration is outside the scope of this specification.
发出经过身份验证的请求需要事先了解服务器的配置。OAuth包括用于通过请求传输协议参数的多种方法（第3.5节），以及用于客户端证明其对所用凭据的合法所有权的多种方法（第3.4节）。客户端发现所需配置的方式超出了本规范的范围。
An authenticated request includes several protocol parameters. Each parameter name begins with the "oauth_" prefix, and the parameter names and values are case sensitive. Clients make authenticated requests by calculating the values of a set of protocol parameters and adding them to the HTTP request as follows:
经过身份验证的请求包括几个协议参数。每个参数名称都以“oauth_”前缀开头，参数名称和值区分大小写。客户端通过计算一组协议参数的值并将其添加到HTTP请求中来发出经过身份验证的请求，如下所示：
1. The client assigns value to each of these REQUIRED (unless specified otherwise) protocol parameters:
1. 客户机为每个所需（除非另有规定）协议参数赋值：
oauth_consumer_key The identifier portion of the client credentials (equivalent to a username). The parameter name reflects a deprecated term (Consumer Key) used in previous revisions of the specification, and has been retained to maintain backward compatibility.
oauth_consumer_key客户端凭据的标识符部分（相当于用户名）。参数名称反映了规范先前版本中使用的不推荐使用的术语（使用者密钥），并已保留该名称以保持向后兼容性。
oauth_token The token value used to associate the request with the resource owner. If the request is not associated with a resource owner (no token available), clients MAY omit the parameter.
oauth_令牌用于将请求与资源所有者关联的令牌值。如果请求未与资源所有者关联（没有可用的令牌），则客户端可能会忽略该参数。
oauth_signature_method The name of the signature method used by the client to sign the request, as defined in Section 3.4.
oauth_signature_method客户端用于签署请求的签名方法的名称，如第3.4节所定义。
oauth_timestamp The timestamp value as defined in Section 3.3. The parameter MAY be omitted when using the "PLAINTEXT" signature method.
oauth_timestamp第3.3节中定义的时间戳值。在使用“明文”签名方法时，可以省略该参数。
oauth_nonce The nonce value as defined in Section 3.3. The parameter MAY be omitted when using the "PLAINTEXT" signature method.
oauth_nonce第3.3节中定义的nonce值。在使用“明文”签名方法时，可以省略该参数。
oauth_version OPTIONAL. If present, MUST be set to "1.0". Provides the version of the authentication process as defined in this specification.
oauth_版本可选。如果存在，则必须设置为“1.0”。提供本规范中定义的身份验证过程的版本。
2. The protocol parameters are added to the request using one of the transmission methods listed in Section 3.5. Each parameter MUST NOT appear more than once per request.
2. 使用第3.5节中列出的传输方法之一将协议参数添加到请求中。每个参数在每个请求中不得出现一次以上。
3. The client calculates and assigns the value of the "oauth_signature" parameter as described in Section 3.4 and adds the parameter to the request using the same method as in the previous step.
3. 客户机按照第3.4节所述计算并分配“oauth_签名”参数的值，并使用与上一步相同的方法将参数添加到请求中。
4. The client sends the authenticated HTTP request to the server.
4. 客户端向服务器发送经过身份验证的HTTP请求。
For example, to make the following HTTP request authenticated (the "c2&a3=2+q" string in the following examples is used to illustrate the impact of a form-encoded entity-body):
例如，要对以下HTTP请求进行身份验证（以下示例中的“c2&a3=2+q”字符串用于说明表单编码实体体的影响）：
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
c2&a3=2+q
c2和a3=2+q
The client assigns values to the following protocol parameters using its client credentials, token credentials, the current timestamp, a uniquely generated nonce, and indicates that it will use the "HMAC-SHA1" signature method:
客户端使用其客户端凭据、令牌凭据、当前时间戳和唯一生成的nonce为以下协议参数赋值，并指示其将使用“HMAC-SHA1”签名方法：
oauth_consumer_key: 9djdj82h48djs9d2 oauth_token: kkk9d7dh3k39sjv7 oauth_signature_method: HMAC-SHA1 oauth_timestamp: 137131201 oauth_nonce: 7d8f3e4a
oauth \-使用者\-密钥：9djdj82h48djs9d2 oauth \-令牌：KK9D7DH3K39SJV7 oauth \-签名方法：HMAC-SHA1 oauth \-时间戳：137131201 oauth \-当前：7d8f3e4a
The client adds the protocol parameters to the request using the OAuth HTTP "Authorization" header field:
客户端使用OAuth HTTP“Authorization”头字段将协议参数添加到请求中：
Authorization: OAuth realm="Example", oauth_consumer_key="9djdj82h48djs9d2", oauth_token="kkk9d7dh3k39sjv7", oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131201", oauth_nonce="7d8f3e4a"
授权：OAuth realm=“示例”，OAuth_consumer=“9djdj82h48djs9d2”，OAuth_token=“kkk9d7dh3k39sjv7”，OAuth_签名方法=“HMAC-SHA1”，OAuth_timestamp=“137131201”，OAuth_nonce=“7d8f3e4a”
Then, it calculates the value of the "oauth_signature" parameter (using client secret "j49sk3j29djd" and token secret "dh893hdasih9"), adds it to the request, and sends the HTTP request to the server:
然后，它计算“oauth_签名”参数的值（使用客户端密码“j49sk3j29djd”和令牌密码“dh893hdasih9”），将其添加到请求中，并将HTTP请求发送到服务器：
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
c2&a3=2+q
c2和a3=2+q
Servers receiving an authenticated request MUST validate it by:
接收经过身份验证的请求的服务器必须通过以下方式进行验证：
o Recalculating the request signature independently as described in Section 3.4 and comparing it to the value received from the client via the "oauth_signature" parameter.
o 如第3.4节所述，独立地重新计算请求签名，并将其与通过“oauth_签名”参数从客户端接收的值进行比较。
o If using the "HMAC-SHA1" or "RSA-SHA1" signature methods, ensuring that the combination of nonce/timestamp/token (if present) received from the client has not been used before in a previous request (the server MAY reject requests with stale timestamps as described in Section 3.3).
o 如果使用“HMAC-SHA1”或“RSA-SHA1”签名方法，确保从客户端接收的nonce/timestamp/token（如果存在）的组合在以前的请求中没有使用过（服务器可能会拒绝具有过时时间戳的请求，如第3.3节所述）。
o If a token is present, verifying the scope and status of the client authorization as represented by the token (the server MAY choose to restrict token usage to the client to which it was issued).
o 如果存在令牌，则验证令牌所代表的客户端授权的范围和状态（服务器可以选择将令牌使用限制在向其发出令牌的客户端）。
o If the "oauth_version" parameter is present, ensuring its value is "1.0".
o 如果存在“oauth_version”参数，请确保其值为“1.0”。
If the request fails verification, the server SHOULD respond with the appropriate HTTP response status code. The server MAY include further details about why the request was rejected in the response body.
如果请求验证失败，服务器应使用适当的HTTP响应状态代码进行响应。服务器可能会在响应正文中包含有关请求被拒绝原因的更多详细信息。
The server SHOULD return a 400 (Bad Request) status code when receiving a request with unsupported parameters, an unsupported signature method, missing parameters, or duplicated protocol parameters. The server SHOULD return a 401 (Unauthorized) status code when receiving a request with invalid client credentials, an invalid or expired token, an invalid signature, or an invalid or used nonce.
当接收到包含不支持的参数、不支持的签名方法、缺少的参数或重复的协议参数的请求时，服务器应返回400（错误请求）状态代码。当接收到具有无效客户端凭据、无效或过期令牌、无效签名或无效或已使用nonce的请求时，服务器应返回401（未经授权）状态代码。
The timestamp value MUST be a positive integer. Unless otherwise specified by the server's documentation, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT.
时间戳值必须是正整数。除非服务器文档另有规定，时间戳以自1970年1月1日00:00:00 GMT起的秒数表示。
A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel. The nonce value MUST be unique across all requests with the same timestamp, client credentials, and token combinations.
nonce是一个随机字符串，由客户端唯一生成，以允许服务器验证以前从未发出过请求，并在通过非安全通道发出请求时帮助防止重播攻击。在具有相同时间戳、客户端凭据和令牌组合的所有请求中，nonce值必须是唯一的。
To avoid the need to retain an infinite number of nonce values for future checks, servers MAY choose to restrict the time period after which a request with an old timestamp is rejected. Note that this restriction implies a level of synchronization between the client's and server's clocks. Servers applying such a restriction MAY provide a way for the client to sync with the server's clock; alternatively, both systems could synchronize with a trusted time service. Details of clock synchronization strategies are beyond the scope of this specification.
为了避免需要为将来的检查保留无限多的nonce值，服务器可以选择限制一个时间段，在该时间段之后，具有旧时间戳的请求将被拒绝。请注意，此限制意味着客户端和服务器时钟之间的同步级别。应用这种限制的服务器可以为客户端提供与服务器时钟同步的方式；或者，两个系统都可以与受信任的时间服务同步。时钟同步策略的详细信息超出本规范的范围。
OAuth-authenticated requests can have two sets of credentials: those passed via the "oauth_consumer_key" parameter and those in the "oauth_token" parameter. In order for the server to verify the authenticity of the request and prevent unauthorized access, the client needs to prove that it is the rightful owner of the credentials. This is accomplished using the shared-secret (or RSA key) part of each set of credentials.
OAuth认证请求可以有两组凭据：通过“OAuth_consumer_key”参数传递的凭据和通过“OAuth_token”参数传递的凭据。为了让服务器验证请求的真实性并防止未经授权的访问，客户端需要证明它是凭据的合法所有者。这是通过使用每组凭证的共享密钥（或RSA密钥）部分实现的。
OAuth provides three methods for the client to prove its rightful ownership of the credentials: "HMAC-SHA1", "RSA-SHA1", and "PLAINTEXT". These methods are generally referred to as signature methods, even though "PLAINTEXT" does not involve a signature. In addition, "RSA-SHA1" utilizes an RSA key instead of the shared-secrets associated with the client credentials.
OAuth为客户端提供了三种方法来证明其对凭证的合法所有权：“HMAC-SHA1”、“RSA-SHA1”和“明文”。这些方法通常称为签名方法，即使“明文”不涉及签名。此外，“RSA-SHA1”使用RSA密钥，而不是与客户端凭据相关联的共享机密。
OAuth does not mandate a particular signature method, as each implementation can have its own unique requirements. Servers are free to implement and document their own custom methods. Recommending any particular method is beyond the scope of this specification. Implementers should review the Security Considerations section (Section 4) before deciding on which method to support.
OAuth并不强制使用特定的签名方法，因为每个实现都有自己独特的需求。服务器可以自由地实现和记录自己的自定义方法。推荐任何特定方法超出本规范的范围。在决定支持哪种方法之前，实现者应该查看安全注意事项部分（第4节）。
The client declares which signature method is used via the "oauth_signature_method" parameter. It then generates a signature (or a string of an equivalent value) and includes it in the "oauth_signature" parameter. The server verifies the signature as specified for each method.
客户机通过“oauth_signature_method”参数声明使用哪个签名方法。然后，它生成一个签名（或一个等价值的字符串），并将其包含在“oauth_signature”参数中。服务器验证为每个方法指定的签名。
The signature process does not change the request or its parameters, with the exception of the "oauth_signature" parameter.
签名过程不会更改请求或其参数，但“oauth_签名”参数除外。
The signature base string is a consistent, reproducible concatenation of several of the HTTP request elements into a single string. The string is used as an input to the "HMAC-SHA1" and "RSA-SHA1" signature methods.
签名基字符串是将多个HTTP请求元素一致、可复制地连接成一个字符串。该字符串用作“HMAC-SHA1”和“RSA-SHA1”签名方法的输入。
The signature base string includes the following components of the HTTP request:
签名基字符串包括HTTP请求的以下组件：
o The HTTP request method (e.g., "GET", "POST", etc.).
o HTTP请求方法（例如，“GET”、“POST”等）。
o The authority as declared by the HTTP "Host" request header field.
o HTTP“主机”请求标头字段声明的权限。
o The path and query components of the request resource URI.
o 请求资源URI的路径和查询组件。
o The protocol parameters excluding the "oauth_signature".
o 协议参数不包括“oauth_签名”。
o Parameters included in the request entity-body if they comply with the strict restrictions defined in Section 3.4.1.3.
o 如果符合第3.4.1.3节中定义的严格限制，则包含在请求实体正文中的参数。
The signature base string does not cover the entire HTTP request. Most notably, it does not include the entity-body in most requests, nor does it include most HTTP entity-headers. It is important to note that the server cannot verify the authenticity of the excluded request components without using additional protections such as SSL/ TLS or other methods.
签名基字符串不包含整个HTTP请求。最值得注意的是，它在大多数请求中不包含实体体，也不包含大多数HTTP实体头。需要注意的是，如果不使用其他保护（如SSL/TLS或其他方法），服务器无法验证排除的请求组件的真实性。
The signature base string is constructed by concatenating together, in order, the following HTTP request elements:
签名基字符串是通过按顺序将以下HTTP请求元素连接在一起构建的：
1. The HTTP request method in uppercase. For example: "HEAD", "GET", "POST", etc. If the request uses a custom HTTP method, it MUST be encoded (Section 3.6).
1. HTTP请求方法是大写的。例如：“HEAD”、“GET”、“POST”等。如果请求使用自定义HTTP方法，则必须对其进行编码（第3.6节）。
2. An "&" character (ASCII code 38).
2. 一个“&”字符（ASCII码38）。
3. The base string URI from Section 3.4.1.2, after being encoded (Section 3.6).
3. 编码后的第3.4.1.2节中的基本字符串URI（第3.6节）。
4. An "&" character (ASCII code 38).
4. 一个“&”字符（ASCII码38）。
5. The request parameters as normalized in Section 3.4.1.3.2, after being encoded (Section 3.6).
5. 第3.4.1.3.2节中规范化的请求参数在编码后（第3.6节）。
For example, the HTTP request:
例如，HTTP请求：
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="bYT5CMsGcbgUdFHObYMEfcx6bsw%3D"
c2&a3=2+q
c2和a3=2+q
is represented by the following signature base string (line breaks are for display purposes only):
由以下签名基字符串表示（换行符仅用于显示）：
POST&http%3A%2F%2Fexample.com%2Frequest&a2%3Dr%2520b%26a3%3D2%2520q %26a3%3Da%26b5%3D%253D%25253D%26c%2540%3D%26c2%3D%26oauth_consumer_ key%3D9djdj82h48djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_m ethod%3DHMAC-SHA1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk 9d7dh3k39sjv7
POST&http%3A%2F%2Example.com%2F请求和a2%3Dr%2520b%26a3%3D2%2520q%26a3%3Da%26b5%3D%253D%25253D%26c%2540%3D%26c2%3D%26oauth用户密钥%3D9DJ82H48DJS9D2%26oauth非货币%3D7d8f3e4a%26oauth非货币签名方法%3DHMAC-SHA1%26oauth非货币时间戳%3D1371201%26oauth非货币%3KDH77SJ7
The scheme, authority, and path of the request resource URI [RFC3986] are included by constructing an "http" or "https" URI representing the request resource (without the query or fragment) as follows:
请求资源URI[RFC3986]的方案、权限和路径通过构造表示请求资源的“http”或“https”URI（不带查询或片段）包括在内，如下所示：
1. The scheme and host MUST be in lowercase.
1. 方案和主机必须为小写。
2. The host and port values MUST match the content of the HTTP request "Host" header field.
2. 主机和端口值必须与HTTP请求“主机”头字段的内容匹配。
3. The port MUST be included if it is not the default port for the scheme, and MUST be excluded if it is the default. Specifically, the port MUST be excluded when making an HTTP request [RFC2616] to port 80 or when making an HTTPS request [RFC2818] to port 443. All other non-default port numbers MUST be included.
3. 如果端口不是方案的默认端口，则必须包含该端口；如果端口是默认端口，则必须排除该端口。具体而言，当向端口80发出HTTP请求[RFC2616]或向端口443发出HTTPS请求[RFC2818]时，必须排除该端口。必须包括所有其他非默认端口号。
For example, the HTTP request:
例如，HTTP请求：
GET /r%20v/X?id=123 HTTP/1.1
Host: EXAMPLE.COM:80
GET /r%20v/X?id=123 HTTP/1.1
Host: EXAMPLE.COM:80
is represented by the base string URI: "http://example.com/r%20v/X".
由基本字符串URI表示：http://example.com/r%20v/X".
In another example, the HTTPS request:
在另一个示例中，HTTPS请求：
GET /?q=1 HTTP/1.1
Host: www.example.net:8080
GET /?q=1 HTTP/1.1
Host: www.example.net:8080
is represented by the base string URI: "https://www.example.net:8080/".
由基本字符串URI表示：https://www.example.net:8080/".
In order to guarantee a consistent and reproducible representation of the request parameters, the parameters are collected and decoded to their original decoded form. They are then sorted and encoded in a particular manner that is often different from their original encoding scheme, and concatenated into a single string.
为了保证请求参数的一致性和可再现性，参数被收集并解码为其原始解码形式。然后以一种通常不同于原始编码方案的特定方式对它们进行排序和编码，并将其连接成单个字符串。
The parameters from the following sources are collected into a single list of name/value pairs:
来自以下来源的参数被收集到名称/值对的单个列表中：
o The query component of the HTTP request URI as defined by [RFC3986], Section 3.4. The query component is parsed into a list of name/value pairs by treating it as an "application/x-www-form-urlencoded" string, separating the names and values and decoding them as defined by [W3C.REC-html40-19980424], Section 17.13.4.
o [RFC3986]第3.4节定义的HTTP请求URI的查询组件。通过将查询组件视为“application/x-www-form-urlencoded”字符串，分离名称和值，并按照[W3C.REC-html40-19980424]第17.13.4节的定义对其进行解码，将其解析为名称/值对列表。
o The OAuth HTTP "Authorization" header field (Section 3.5.1) if present. The header's content is parsed into a list of name/value pairs excluding the "realm" parameter if present. The parameter values are decoded as defined by Section 3.5.1.
o OAuth HTTP“授权”标头字段（第3.5.1节），如果存在。标头的内容被解析为名称/值对列表，不包括“realm”参数（如果存在）。参数值按照第3.5.1节的规定进行解码。
o The HTTP request entity-body, but only if all of the following conditions are met:
o HTTP请求实体主体，但仅当满足以下所有条件时：
* The entity-body is single-part.
* 实体实体是单个零件。
* The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by [W3C.REC-html40-19980424].
* 实体主体遵循[W3C.REC-html40-19980424]定义的“application/x-www-form-urlencoded”内容类型的编码要求。
* The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded".
* HTTP请求实体标头包括设置为“application/x-www-form-urlencoded”的“Content-Type”标头字段。
The entity-body is parsed into a list of decoded name/value pairs as described in [W3C.REC-html40-19980424], Section 17.13.4.
实体主体被解析为解码名称/值对列表，如[W3C.REC-html40-19980424]第17.13.4节所述。
The "oauth_signature" parameter MUST be excluded from the signature base string if present. Parameters not explicitly included in the request MUST be excluded from the signature base string (e.g., the "oauth_version" parameter when omitted).
如果存在“oauth_签名”参数，则必须将其从签名基字符串中排除。请求中未明确包含的参数必须从签名基字符串中排除（例如，省略时的“oauth_version”参数）。
For example, the HTTP request:
例如，HTTP请求：
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="djosJKDKJSD8743243%2Fjdk33klY%3D"
c2&a3=2+q
c2和a3=2+q
contains the following (fully decoded) parameters used in the signature base sting:
包含在签名基sting中使用的以下（完全解码）参数：
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| b5 | =%3D |
| a3 | a |
| c@ | |
| a2 | r b |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| c2 | |
| a3 | 2 q |
+------------------------+------------------+
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| b5 | =%3D |
| a3 | a |
| c@ | |
| a2 | r b |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| c2 | |
| a3 | 2 q |
+------------------------+------------------+
Note that the value of "b5" is "=%3D" and not "==". Both "c@" and "c2" have empty values. While the encoding rules specified in this specification for the purpose of constructing the signature base string exclude the use of a "+" character (ASCII code 43) to represent an encoded space character (ASCII code 32), this practice is widely used in "application/x-www-form-urlencoded" encoded values, and MUST be properly decoded, as demonstrated by one of the "a3" parameter instances (the "a3" parameter is used twice in this request).
注意，“b5”的值是“=%3D”，而不是“==”。“c@”和“c2”都有空值。虽然本规范中规定的用于构造签名基字符串的编码规则不包括使用“+”字符（ASCII代码43）来表示编码的空格字符（ASCII代码32），但这种做法在“application/x-www-form-urlencoded”编码值中广泛使用，并且必须正确解码，如其中一个“a3”参数实例所示（“a3”参数在此请求中使用了两次）。
The parameters collected in Section 3.4.1.3 are normalized into a single string as follows:
第3.4.1.3节中收集的参数标准化为单个字符串，如下所示：
1. First, the name and value of each parameter are encoded (Section 3.6).
1. 首先，对每个参数的名称和值进行编码（第3.6节）。
2. The parameters are sorted by name, using ascending byte value ordering. If two or more parameters share the same name, they are sorted by their value.
2. 参数按名称排序，使用升序字节值排序。如果两个或多个参数共享相同的名称，则将按其值对其进行排序。
3. The name of each parameter is concatenated to its corresponding value using an "=" character (ASCII code 61) as a separator, even if the value is empty.
3. 使用“=”字符（ASCII代码61）作为分隔符，将每个参数的名称连接到其相应的值，即使该值为空。
4. The sorted name/value pairs are concatenated together into a single string by using an "&" character (ASCII code 38) as separator.
4. 通过使用“&”字符（ASCII代码38）作为分隔符，将已排序的名称/值对连接在一起，形成单个字符串。
For example, the list of parameters from the previous section would be normalized as follows:
例如，前一节中的参数列表将标准化如下：
Encoded:
编码：
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| b5 | %3D%253D |
| a3 | a |
| c%40 | |
| a2 | r%20b |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| c2 | |
| a3 | 2%20q |
+------------------------+------------------+
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| b5 | %3D%253D |
| a3 | a |
| c%40 | |
| a2 | r%20b |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_token | kkk9d7dh3k39sjv7 |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_nonce | 7d8f3e4a |
| c2 | |
| a3 | 2%20q |
+------------------------+------------------+
Sorted:
分类：
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| a2 | r%20b |
| a3 | 2%20q |
| a3 | a |
| b5 | %3D%253D |
| c%40 | |
| c2 | |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_nonce | 7d8f3e4a |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_token | kkk9d7dh3k39sjv7 |
+------------------------+------------------+
+------------------------+------------------+
| Name | Value |
+------------------------+------------------+
| a2 | r%20b |
| a3 | 2%20q |
| a3 | a |
| b5 | %3D%253D |
| c%40 | |
| c2 | |
| oauth_consumer_key | 9djdj82h48djs9d2 |
| oauth_nonce | 7d8f3e4a |
| oauth_signature_method | HMAC-SHA1 |
| oauth_timestamp | 137131201 |
| oauth_token | kkk9d7dh3k39sjv7 |
+------------------------+------------------+
Concatenated Pairs:
连接对：
+-------------------------------------+
| Name=Value |
+-------------------------------------+
| a2=r%20b |
| a3=2%20q |
| a3=a |
| b5=%3D%253D |
| c%40= |
| c2= |
| oauth_consumer_key=9djdj82h48djs9d2 |
| oauth_nonce=7d8f3e4a |
| oauth_signature_method=HMAC-SHA1 |
| oauth_timestamp=137131201 |
| oauth_token=kkk9d7dh3k39sjv7 |
+-------------------------------------+
+-------------------------------------+
| Name=Value |
+-------------------------------------+
| a2=r%20b |
| a3=2%20q |
| a3=a |
| b5=%3D%253D |
| c%40= |
| c2= |
| oauth_consumer_key=9djdj82h48djs9d2 |
| oauth_nonce=7d8f3e4a |
| oauth_signature_method=HMAC-SHA1 |
| oauth_timestamp=137131201 |
| oauth_token=kkk9d7dh3k39sjv7 |
+-------------------------------------+
and concatenated together into a single string (line breaks are for display purposes only):
并连接到一个字符串中（换行符仅用于显示）：
a2=r%20b&a3=2%20q&a3=a&b5=%3D%253D&c%40=&c2=&oauth_consumer_key=9dj
dj82h48djs9d2&oauth_nonce=7d8f3e4a&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=137131201&oauth_token=kkk9d7dh3k39sjv7
a2=r%20b&a3=2%20q&a3=a&b5=%3D%253D&c%40=&c2=&oauth_consumer_key=9dj
dj82h48djs9d2&oauth_nonce=7d8f3e4a&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=137131201&oauth_token=kkk9d7dh3k39sjv7
The "HMAC-SHA1" signature method uses the HMAC-SHA1 signature algorithm as defined in [RFC2104]:
“HMAC-SHA1”签名方法使用[RFC2104]中定义的HMAC-SHA1签名算法：
digest = HMAC-SHA1 (key, text)
摘要=HMAC-SHA1（键，文本）
The HMAC-SHA1 function variables are used in following way:
HMAC-SHA1函数变量的使用方式如下：
text is set to the value of the signature base string from Section 3.4.1.1.
文本设置为第3.4.1.1节中签名基字符串的值。
key is set to the concatenated values of:
键设置为以下串联值：
1. The client shared-secret, after being encoded (Section 3.6).
1. 客户机在编码后共享秘密（第3.6节）。
2. An "&" character (ASCII code 38), which MUST be included even when either secret is empty.
2. 一个“&”字符（ASCII码38），即使其中一个密码为空，也必须包含该字符。
3. The token shared-secret, after being encoded (Section 3.6).
3. 编码后的令牌共享秘密（第3.6节）。
digest is used to set the value of the "oauth_signature" protocol parameter, after the result octet string is base64-encoded per [RFC2045], Section 6.8.
摘要用于根据[RFC2045]第6.8节对结果八位字节字符串进行base64编码后，设置“oauth_签名”协议参数的值。
The "RSA-SHA1" signature method uses the RSASSA-PKCS1-v1_5 signature algorithm as defined in [RFC3447], Section 8.2 (also known as PKCS#1), using SHA-1 as the hash function for EMSA-PKCS1-v1_5. To use this method, the client MUST have established client credentials with the server that included its RSA public key (in a manner that is beyond the scope of this specification).
“RSA-SHA1”签名方法使用[RFC3447]第8.2节中定义的RSASSA-PKCS1-v1_5签名算法（也称为PKCS#1），使用SHA-1作为EMSA-PKCS1-v1_5的哈希函数。要使用此方法，客户端必须与包含其RSA公钥的服务器建立客户端凭据（以超出本规范范围的方式）。
The signature base string is signed using the client's RSA private key per [RFC3447], Section 8.2.1:
根据[RFC3447]，第8.2.1节，使用客户端的RSA私钥对签名基字符串进行签名：
S = RSASSA-PKCS1-V1_5-SIGN (K, M)
S=RSASSA-PKCS1-V1_5-符号（K，M）
Where:
哪里：
K is set to the client's RSA private key,
K设置为客户端的RSA私钥，
M is set to the value of the signature base string from Section 3.4.1.1, and
M设置为第3.4.1.1节中签名基字符串的值，以及
S is the result signature used to set the value of the "oauth_signature" protocol parameter, after the result octet string is base64-encoded per [RFC2045] section 6.8.
S是根据[RFC2045]第6.8节对结果八位字节字符串进行base64编码后，用于设置“oauth_签名”协议参数值的结果签名。
The server verifies the signature per [RFC3447] section 8.2.2:
服务器根据[RFC3447]第8.2.2节验证签名：
RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
RSASSA-PKCS1-V1_5-验证（北、东、南）
Where:
哪里：
(n, e) is set to the client's RSA public key,
（n，e）设置为客户端的RSA公钥，
M is set to the value of the signature base string from Section 3.4.1.1, and
M设置为第3.4.1.1节中签名基字符串的值，以及
S is set to the octet string value of the "oauth_signature" protocol parameter received from the client.
S设置为从客户端接收的“oauth_签名”协议参数的八位字符串值。
The "PLAINTEXT" method does not employ a signature algorithm. It MUST be used with a transport-layer mechanism such as TLS or SSL (or sent over a secure channel with equivalent protections). It does not utilize the signature base string or the "oauth_timestamp" and "oauth_nonce" parameters.
“明文”方法不使用签名算法。它必须与传输层机制（如TLS或SSL）一起使用（或通过具有同等保护的安全通道发送）。它不使用签名基字符串或“oauth_timestamp”和“oauth_nonce”参数。
The "oauth_signature" protocol parameter is set to the concatenated value of:
“oauth_signature”协议参数设置为串联值：
1. The client shared-secret, after being encoded (Section 3.6).
1. 客户机在编码后共享秘密（第3.6节）。
2. An "&" character (ASCII code 38), which MUST be included even when either secret is empty.
2. 一个“&”字符（ASCII码38），即使其中一个密码为空，也必须包含该字符。
3. The token shared-secret, after being encoded (Section 3.6).
3. 编码后的令牌共享秘密（第3.6节）。
When making an OAuth-authenticated request, protocol parameters as well as any other parameter using the "oauth_" prefix SHALL be included in the request using one and only one of the following locations, listed in order of decreasing preference:
当发出OAuth认证请求时，协议参数以及使用“OAuth_u2;”前缀的任何其他参数应包含在请求中，使用以下位置中的一个且仅一个，按优先顺序递减列出：
1. The HTTP "Authorization" header field as described in Section 3.5.1.
1. HTTP“Authorization”标头字段，如第3.5.1节所述。
2. The HTTP request entity-body as described in Section 3.5.2.
2. HTTP请求实体主体，如第3.5.2节所述。
3. The HTTP request URI query as described in Section 3.5.3.
3. HTTP请求URI查询如第3.5.3节所述。
In addition to these three methods, future extensions MAY define other methods for including protocol parameters in the request.
除了这三种方法之外，未来的扩展可能会定义在请求中包含协议参数的其他方法。
Protocol parameters can be transmitted using the HTTP "Authorization" header field as defined by [RFC2617] with the auth-scheme name set to "OAuth" (case insensitive).
协议参数可以使用[RFC2617]定义的HTTP“Authorization”头字段进行传输，auth方案名称设置为“OAuth”（不区分大小写）。
For example:
例如：
Authorization: OAuth realm="Example", oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7", oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D", oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176", oauth_version="1.0"
授权：OAuth realm=“Example”、OAuth_consumer_key=“0685bd9184jfhq22”、OAuth_token=“ad180jjd733klru7”、OAuth_signature_method=“HMAC-SHA1”、OAuth_signature=“wOJIO9A2W5mFwDgiDvZbTSMK%2PY%3D”、OAuth_timestamp=“137131200”、OAuth_nonce=“4572616E486116D65724C616686176”、OAuth_version=“1.0”
Protocol parameters SHALL be included in the "Authorization" header field as follows:
协议参数应包括在“授权”标题字段中，如下所示：
1. Parameter names and values are encoded per Parameter Encoding (Section 3.6).
1. 参数名称和值按照参数编码进行编码（第3.6节）。
2. Each parameter's name is immediately followed by an "=" character (ASCII code 61), a """ character (ASCII code 34), the parameter value (MAY be empty), and another """ character (ASCII code 34).
2. 每个参数的名称后面紧跟着一个“=”字符（ASCII代码61）、一个“？”字符（ASCII代码34）、参数值（可能为空）和另一个“？”字符（ASCII代码34）。
3. Parameters are separated by a "," character (ASCII code 44) and OPTIONAL linear whitespace per [RFC2617].
3. 根据[RFC2617]，参数由“，”字符（ASCII代码44）和可选线性空白分隔。
4. The OPTIONAL "realm" parameter MAY be added and interpreted per [RFC2617] section 1.2.
4. 可根据[RFC2617]第1.2节添加和解释可选的“领域”参数。
Servers MAY indicate their support for the "OAuth" auth-scheme by returning the HTTP "WWW-Authenticate" response header field upon client requests for protected resources. As per [RFC2617], such a response MAY include additional HTTP "WWW-Authenticate" header fields:
服务器可以通过在客户端请求受保护资源时返回HTTP“WWW Authenticate”响应头字段来表明其对“OAuth”身份验证方案的支持。根据[RFC2617]，这样的响应可以包括额外的HTTP“WWW认证”头字段：
For example:
例如：
WWW-Authenticate: OAuth realm="http://server.example.com/"
WWW-Authenticate: OAuth realm="http://server.example.com/"
The realm parameter defines a protection realm per [RFC2617], Section 1.2.
领域参数根据[RFC2617]第1.2节定义保护领域。
Protocol parameters can be transmitted in the HTTP request entity-body, but only if the following REQUIRED conditions are met:
协议参数可以在HTTP请求实体体中传输，但前提是满足以下所需条件：
o The entity-body is single-part.
o 实体实体是单个零件。
o The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by [W3C.REC-html40-19980424].
o 实体主体遵循[W3C.REC-html40-19980424]定义的“application/x-www-form-urlencoded”内容类型的编码要求。
o The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded".
o HTTP请求实体标头包括设置为“application/x-www-form-urlencoded”的“Content-Type”标头字段。
For example (line breaks are for display purposes only):
例如（换行符仅用于显示目的）：
oauth_consumer_key=0685bd9184jfhq22&oauth_token=ad180jjd733klr
u7&oauth_signature_method=HMAC-SHA1&oauth_signature=wOJIO9A2W5
mFwDgiDvZbTSMK%2FPY%3D&oauth_timestamp=137131200&oauth_nonce=4
572616e48616d6d65724c61686176&oauth_version=1.0
oauth_consumer_key=0685bd9184jfhq22&oauth_token=ad180jjd733klr
u7&oauth_signature_method=HMAC-SHA1&oauth_signature=wOJIO9A2W5
mFwDgiDvZbTSMK%2FPY%3D&oauth_timestamp=137131200&oauth_nonce=4
572616e48616d6d65724c61686176&oauth_version=1.0
The entity-body MAY include other request-specific parameters, in which case, the protocol parameters SHOULD be appended following the request-specific parameters, properly separated by an "&" character (ASCII code 38).
实体主体可包括其他特定于请求的参数，在这种情况下，协议参数应附加在特定于请求的参数之后，并用“&”字符（ASCII代码38）正确分隔。
Protocol parameters can be transmitted by being added to the HTTP request URI as a query parameter as defined by [RFC3986], Section 3.
协议参数可以通过添加到HTTP请求URI中作为[RFC3986]第3节定义的查询参数来传输。
For example (line breaks are for display purposes only):
例如（换行符仅用于显示目的）：
GET /example/path?oauth_consumer_key=0685bd9184jfhq22&
oauth_token=ad180jjd733klru7&oauth_signature_method=HM
AC-SHA1&oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%
3D&oauth_timestamp=137131200&oauth_nonce=4572616e48616
d6d65724c61686176&oauth_version=1.0 HTTP/1.1
GET /example/path?oauth_consumer_key=0685bd9184jfhq22&
oauth_token=ad180jjd733klru7&oauth_signature_method=HM
AC-SHA1&oauth_signature=wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%
3D&oauth_timestamp=137131200&oauth_nonce=4572616e48616
d6d65724c61686176&oauth_version=1.0 HTTP/1.1
The request URI MAY include other request-specific query parameters, in which case, the protocol parameters SHOULD be appended following the request-specific parameters, properly separated by an "&" character (ASCII code 38).
请求URI可以包括其他特定于请求的查询参数，在这种情况下，协议参数应该附加在特定于请求的参数之后，并用“&”字符正确分隔（ASCII代码38）。
Existing percent-encoding methods do not guarantee a consistent construction of the signature base string. The following percent-encoding method is not defined to replace the existing encoding methods defined by [RFC3986] and [W3C.REC-html40-19980424]. It is used only in the construction of the signature base string and the "Authorization" header field.
现有的百分比编码方法不能保证签名基字符串的一致构造。以下百分比编码方法未定义为取代[RFC3986]和[W3C.REC-html40-19980424]定义的现有编码方法。它仅用于构造签名基字符串和“Authorization”头字段。
This specification defines the following method for percent-encoding strings:
本规范定义了以下百分比编码字符串的方法：
1. Text values are first encoded as UTF-8 octets per [RFC3629] if they are not already. This does not include binary values that are not intended for human consumption.
1. 如果文本值尚未编码，则首先按照[RFC3629]将其编码为UTF-8八位字节。这不包括不供人类使用的二进制值。
2. The values are then escaped using the [RFC3986] percent-encoding (%XX) mechanism as follows:
2. 然后使用[RFC3986]百分比编码（%XX）机制对值进行转义，如下所示：
* Characters in the unreserved character set as defined by [RFC3986], Section 2.3 (ALPHA, DIGIT, "-", ".", "_", "~") MUST NOT be encoded.
* 不得对[RFC3986]第2.3节定义的无保留字符集中的字符进行编码（字母、数字、“-”、“”、“~”）。
* All other characters MUST be encoded.
* 所有其他字符都必须进行编码。
* The two hexadecimal characters used to represent encoded characters MUST be uppercase.
* 用于表示编码字符的两个十六进制字符必须为大写。
This method is different from the encoding scheme used by the "application/x-www-form-urlencoded" content-type (for example, it encodes space characters as "%20" and not using the "+" character). It MAY be different from the percent-encoding functions provided by web-development frameworks (e.g., encode different characters, use lowercase hexadecimal characters).
此方法不同于“application/x-www-form-urlencoded”内容类型使用的编码方案（例如，它将空格字符编码为“%20”，而不使用“+”字符）。它可能不同于web开发框架提供的百分比编码函数（例如，编码不同的字符，使用小写十六进制字符）。
As stated in [RFC2617], the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. Implementers are strongly encouraged to assess how this protocol addresses their security requirements.
如[RFC2617]所述，最大的风险来源通常不在核心协议本身，而是在围绕其使用的政策和程序中。强烈鼓励实施者评估该协议如何满足其安全需求。
Authenticated requests made with "RSA-SHA1" signatures do not use the token shared-secret, or any provisioned client shared-secret. This means the request relies completely on the secrecy of the private key used by the client to sign requests.
使用“RSA-SHA1”签名进行的身份验证请求不使用令牌共享密钥或任何已设置的客户端共享密钥。这意味着请求完全依赖于客户端用于签署请求的私钥的保密性。
While this protocol provides a mechanism for verifying the integrity of requests, it provides no guarantee of request confidentiality. Unless further precautions are taken, eavesdroppers will have full access to request content. Servers should carefully consider the kinds of data likely to be sent as part of such requests, and should employ transport-layer security mechanisms to protect sensitive resources.
虽然该协议提供了一种验证请求完整性的机制，但它不能保证请求的机密性。除非采取进一步的预防措施，否则窃听者将完全可以访问请求内容。服务器应仔细考虑作为这种请求的一部分可能发送的数据类型，并应采用传输层安全机制来保护敏感资源。
This protocol makes no attempt to verify the authenticity of the server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services using this protocol, and should require transport-layer security for any requests where the authenticity of the server or of request responses is an issue.
此协议不尝试验证服务器的真实性。敌对方可以通过拦截客户的请求并返回误导性或其他不正确的响应来利用这一点。服务提供商应该在使用该协议开发服务时考虑此类攻击，并且对于服务器的真实性或请求响应是一个问题的任何请求，都应该要求传输层安全。
The HTTP Authorization scheme (Section 3.5.1) is optional. However, [RFC2616] relies on the "Authorization" and "WWW-Authenticate" header fields to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these header fields.
HTTP授权方案（第3.5.1节）是可选的。但是，[RFC2616]依赖“Authorization”和“WWW Authenticate”头字段来区分经过身份验证的内容，以便对其进行保护。特别是，代理和缓存可能无法充分保护不使用这些头字段的请求。
For example, private authenticated content may be stored in (and thus retrievable from) publicly accessible caches. Servers not using the HTTP "Authorization" header field should take care to use other mechanisms, such as the "Cache-Control" header field, to ensure that authenticated content is protected.
例如，私有认证内容可以存储在（因此可以从）可公开访问的缓存中。未使用HTTP“Authorization”标头字段的服务器应注意使用其他机制，如“Cache Control”标头字段，以确保已验证的内容受到保护。
The client shared-secret and token shared-secret function the same way passwords do in traditional authentication systems. In order to compute the signatures used in methods other than "RSA-SHA1", the server must have access to these secrets in plaintext form. This is in contrast, for example, to modern operating systems, which store only a one-way hash of user credentials.
客户端共享密钥和令牌共享密钥的功能与传统身份验证系统中的密码相同。为了计算“RSA-SHA1”以外的方法中使用的签名，服务器必须能够以明文形式访问这些机密。例如，这与现代操作系统相反，现代操作系统只存储用户凭证的单向散列。
If an attacker were to gain access to these secrets -- or worse, to the server's database of all such secrets -- he or she would be able to perform any action on behalf of any resource owner. Accordingly, it is critical that servers protect these secrets from unauthorized access.
如果攻击者能够访问这些机密——或者更糟的是，访问服务器上所有此类机密的数据库——他或她将能够代表任何资源所有者执行任何操作。因此，服务器必须保护这些机密，防止未经授权的访问。
In many cases, the client application will be under the control of potentially untrusted parties. For example, if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials.
在许多情况下，客户端应用程序将处于潜在不受信任方的控制之下。例如，如果客户端是具有免费源代码或可执行二进制文件的桌面应用程序，则攻击者可以下载副本进行分析。在这种情况下，攻击者将能够恢复客户端凭据。
Accordingly, servers should not use the client credentials alone to verify the identity of the client. Where possible, other factors such as IP address should be used as well.
因此，服务器不应单独使用客户端凭据来验证客户端的身份。在可能的情况下，还应使用其他因素，如IP地址。
Wide deployment of this and similar protocols may cause resource owners to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If resource owners are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal resource owners' passwords.
此协议和类似协议的广泛部署可能会导致资源所有者习惯于被重定向到要求他们输入密码的网站。如果资源所有者在输入其凭据之前不小心验证这些网站的真实性，攻击者就有可能利用这种做法窃取资源所有者的密码。
Servers should attempt to educate resource owners about the risks phishing attacks pose, and should provide mechanisms that make it easy for resource owners to confirm the authenticity of their sites. Client developers should consider the security implications of how they interact with a user-agent (e.g., separate window, embedded), and the ability of the end-user to verify the authenticity of the server website.
服务器应尝试向资源所有者介绍钓鱼攻击带来的风险，并应提供机制，使资源所有者能够轻松确认其站点的真实性。客户端开发人员应该考虑它们如何与用户代理（例如，单独的窗口、嵌入式）交互的安全含义，以及终端用户验证服务器网站的真实性的能力。
By itself, this protocol does not provide any method for scoping the access rights granted to a client. However, most applications do require greater granularity of access rights. For example, servers may wish to make it possible to grant access to some protected resources but not others, or to grant only limited access (such as read-only access) to those protected resources.
就其本身而言，该协议不提供任何方法来确定授予客户端的访问权限的范围。但是，大多数应用程序确实需要更大的访问权限粒度。例如，服务器可能希望能够授予对某些受保护资源的访问权，但不授予对其他资源的访问权，或者仅授予对这些受保护资源的有限访问权（例如只读访问权）。
When implementing this protocol, servers should consider the types of access resource owners may wish to grant clients, and should provide mechanisms to do so. Servers should also take care to ensure that resource owners understand the access they are granting, as well as any risks that may be involved.
在执行该协议时，服务器应该考虑访问资源所有者可能希望授予客户端的类型，并且应该提供这样的机制。服务器还应注意确保资源所有者了解他们授予的访问权限以及可能涉及的任何风险。
Unless a transport-layer security protocol is used, eavesdroppers will have full access to authenticated requests and signatures, and will thus be able to mount offline brute-force attacks to recover the credentials used. Servers should be careful to assign shared-secrets that are long enough, and random enough, to resist such attacks for at least the length of time that the shared-secrets are valid.
除非使用传输层安全协议，否则窃听者将拥有对经过身份验证的请求和签名的完全访问权限，从而能够发起离线暴力攻击以恢复所使用的凭据。服务器应谨慎地分配足够长、足够随机的共享机密，以抵抗此类攻击，至少在共享机密有效的时间长度内。
For example, if shared-secrets are valid for two weeks, servers should ensure that it is not possible to mount a brute force attack that recovers the shared-secret in less than two weeks. Of course, servers are urged to err on the side of caution, and use the longest secrets reasonable.
例如，如果共享机密在两周内有效，服务器应确保不可能在两周内发起暴力攻击来恢复共享机密。当然，服务器必须谨慎行事，使用最长的机密。
It is equally important that the pseudo-random number generator (PRNG) used to generate these secrets be of sufficiently high quality. Many PRNG implementations generate number sequences that may appear to be random, but that nevertheless exhibit patterns or other weaknesses that make cryptanalysis or brute force attacks easier. Implementers should be careful to use cryptographically secure PRNGs to avoid these problems.
同样重要的是，用于生成这些秘密的伪随机数生成器（PRNG）必须具有足够高的质量。许多PRNG实现生成的数字序列看起来可能是随机的，但仍然显示出模式或其他弱点，使密码分析或暴力攻击更容易。实现者应该小心使用加密安全的PRNG来避免这些问题。
This specification includes a number of features that may make resource exhaustion attacks against servers possible. For example, this protocol requires servers to track used nonces. If an attacker is able to use many nonces quickly, the resources required to track them may exhaust available capacity. And again, this protocol can require servers to perform potentially expensive computations in order to verify the signature on incoming requests. An attacker may exploit this to perform a denial-of-service attack by sending a large number of invalid requests to the server.
此规范包括许多可能使针对服务器的资源耗尽攻击成为可能的功能。例如，此协议要求服务器跟踪使用的nonce。如果攻击者能够快速使用多个nonce，则跟踪它们所需的资源可能会耗尽可用容量。同样，该协议可能要求服务器执行可能昂贵的计算，以便验证传入请求的签名。攻击者可利用此漏洞向服务器发送大量无效请求，从而执行拒绝服务攻击。
Resource Exhaustion attacks are by no means specific to this specification. However, implementers should be careful to consider the additional avenues of attack that this protocol exposes, and design their implementations accordingly. For example, entropy starvation typically results in either a complete denial of service while the system waits for new entropy or else in weak (easily guessable) secrets. When implementing this protocol, servers should consider which of these presents a more serious risk for their application and design accordingly.
资源耗尽攻击决不是本规范所特有的。然而，实现者应该仔细考虑该协议公开的攻击的额外途径，并相应地设计它们的实现。例如，当系统等待新的熵时，熵饥饿通常会导致完全拒绝服务，或者导致弱（容易猜测）秘密。在执行该协议时，服务器应该考虑哪些对它们的应用和设计提出了更严重的风险。
SHA-1, the hash algorithm used in "HMAC-SHA1" and "RSA-SHA1" signature methods, has been shown to have a number of cryptographic weaknesses that significantly reduce its resistance to collision attacks. While these weaknesses do not seem to affect the use of SHA-1 with the Hash-based Message Authentication Code (HMAC) and should not affect the "HMAC-SHA1" signature method, it may affect the use of the "RSA-SHA1" signature method. NIST has announced that it will phase out use of SHA-1 in digital signatures by 2010 [NIST_SHA-1Comments].
“HMAC-SHA1”和“RSA-SHA1”签名方法中使用的哈希算法SHA-1已被证明存在许多密码弱点，这些弱点显著降低了其抗冲突攻击的能力。虽然这些弱点似乎不会影响SHA-1与基于哈希的消息身份验证码（HMAC）的使用，也不会影响“HMAC-SHA1”签名方法，但可能会影响“RSA-SHA1”签名方法的使用。NIST已宣布将在2010年前逐步淘汰SHA-1在数字签名中的使用[NIST_SHA-1承诺]。
Practically speaking, these weaknesses are difficult to exploit, and by themselves do not pose a significant risk to users of this protocol. They may, however, make more efficient attacks possible, and servers should take this into account when considering whether SHA-1 provides an adequate level of security for their applications.
实际上，这些弱点很难利用，而且本身不会对该协议的用户构成重大风险。但是，它们可能使更有效的攻击成为可能，服务器在考虑SHA-1是否为其应用程序提供足够的安全级别时应考虑到这一点。
The signature base string has been designed to support the signature methods defined in this specification. Those designing additional signature methods, should evaluated the compatibility of the signature base string with their security requirements.
签名基字符串被设计为支持本规范中定义的签名方法。设计附加签名方法的人员应评估签名基字符串与其安全要求的兼容性。
Since the signature base string does not cover the entire HTTP request, such as most request entity-body, most entity-headers, and the order in which parameters are sent, servers should employ additional mechanisms to protect such elements.
由于签名基字符串不包括整个HTTP请求，例如大多数请求实体体、大多数实体头以及发送参数的顺序，因此服务器应该使用其他机制来保护这些元素。
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on authorization approvals can allow an attacker to obtain authorization to protected resources without the consent of the User. Servers SHOULD strongly consider best practices in CSRF prevention at all the protocol authorization endpoints.
跨站点请求伪造（CSRF）是一种基于web的攻击，通过这种攻击，HTTP请求从网站信任或已认证的用户处传输。对授权批准的CSRF攻击可使攻击者在未经用户同意的情况下获得受保护资源的授权。服务器应该在所有的协议授权端点中强烈考虑CSRF预防的最佳实践。
CSRF attacks on OAuth callback URIs hosted by clients are also possible. Clients should prevent CSRF attacks on OAuth callback URIs by verifying that the resource owner at the client site intended to complete the OAuth negotiation with the server. The methods for preventing such CSRF attacks are beyond the scope of this specification.
也可能对客户端托管的OAuth回调URI进行CSRF攻击。客户端应通过验证客户端站点的资源所有者是否打算完成与服务器的OAuth协商来防止对OAuth回调URI的CSRF攻击。防止此类CSRF攻击的方法超出了本规范的范围。
Servers should protect the authorization process against user interface (UI) redress attacks (also known as "clickjacking"). As of the time of this writing, no complete defenses against UI redress are available. Servers can mitigate the risk of UI redress attacks using the following techniques:
服务器应保护授权过程免受用户界面（UI）攻击（也称为“点击劫持”）。截至本文撰写之时，还没有针对UI补救的完整防御措施。服务器可以使用以下技术降低UI补救攻击的风险：
o JavaScript frame busting.
o JavaScript框架破坏。
o JavaScript frame busting, and requiring that browsers have JavaScript enabled on the authorization page.
o JavaScript框架破坏，并要求浏览器在授权页面上启用JavaScript。
o Browser-specific anti-framing techniques.
o 特定于浏览器的反框架技术。
o Requiring password reentry before issuing OAuth tokens.
o 要求在发出OAuth令牌之前重新输入密码。
Servers may wish to automatically process authorization requests (Section 2.2) from clients that have been previously authorized by the resource owner. When the resource owner is redirected to the server to grant access, the server detects that the resource owner has already granted access to that particular client. Instead of prompting the resource owner for approval, the server automatically redirects the resource owner back to the client.
服务器可能希望自动处理来自资源所有者先前授权的客户端的授权请求（第2.2节）。当资源所有者被重定向到服务器以授予访问权限时，服务器检测到资源所有者已授予对该特定客户端的访问权限。服务器不会提示资源所有者进行批准，而是自动将资源所有者重定向回客户端。
If the client credentials are compromised, automatic processing creates additional security risks. An attacker can use the stolen client credentials to redirect the resource owner to the server with an authorization request. The server will then grant access to the resource owner's data without the resource owner's explicit approval, or even awareness of an attack. If no automatic approval is implemented, an attacker must use social engineering to convince the resource owner to approve access.
如果客户端凭据受损，则自动处理会产生额外的安全风险。攻击者可以使用被盗的客户端凭据通过授权请求将资源所有者重定向到服务器。然后，服务器将授予对资源所有者数据的访问权，而无需资源所有者的明确批准，甚至无需意识到攻击。如果未实现自动批准，攻击者必须使用社会工程说服资源所有者批准访问。
Servers can mitigate the risks associated with automatic processing by limiting the scope of token credentials obtained through automated approvals. Tokens credentials obtained through explicit resource owner consent can remain unaffected. Clients can mitigate the risks associated with automatic processing by protecting their client credentials.
服务器可以通过限制通过自动批准获得的令牌凭据的范围来降低与自动处理相关的风险。通过明确的资源所有者同意获得的令牌凭据可以保持不受影响。客户端可以通过保护其客户端凭据来降低与自动处理相关的风险。
This specification is directly based on the OAuth Core 1.0 Revision A community specification, which in turn was modeled after existing proprietary protocols and best practices that have been independently implemented by various companies.
本规范直接基于OAuth Core 1.0修订版A社区规范，而该规范又是根据各公司独立实施的现有专有协议和最佳实践建模的。
The community specification was edited by Eran Hammer-Lahav and authored by: Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer-Lahav, Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
社区规范由Eran Hammer Lahav编辑，作者：Mark Atwood、Dirk Balfanz、Darren Bounds、Richard M.Conlan、Blaine Cook、Leah Culver、Breno de Medeiros、Brian Eaton、Kellan Elliott McCrea、Larry Halff、Eran Hammer Lahav、Ben Laurie、Chris Messina、John Panzer、Sam Quigley、David Recordon、Eran Sandler、，Jonathan Sergent、Todd Sieling、Brian Slesinsky和Andy Smith。
The editor would like to thank the following individuals for their invaluable contribution to the publication of this edition of the protocol: Lisa Dusseault, Justin Hart, Avshalom Houri, Chris Messina, Mark Nottingham, Tim Polk, Peter Saint-Andre, Joseph Smarr, and Paul Walker.
编辑谨感谢以下个人对本版协议的出版做出的宝贵贡献：丽莎·杜肖奥、贾斯汀·哈特、阿夫沙洛姆·胡里、克里斯·梅西纳、马克·诺丁汉、蒂姆·波尔克、彼得·圣安德烈、约瑟夫·斯马尔和保罗·沃克。
This specification includes the following changes made to the original community document [OAuthCore1.0_RevisionA] in order to correct mistakes and omissions identified since the document was originally published at <http://oauth.net>.
本规范包括对原始社区文件[OAuthCore1.0U RevisionA]所做的以下更改，以纠正自文件最初在<http://oauth.net>.
o Changed using TLS/SSL when sending or requesting plain text credentials from SHOULD to MUST. This change affects any use of the "PLAINTEXT" signature method, as well as requesting temporary credentials (Section 2.1) and obtaining token credentials (Section 2.3).
o 从“应”向“必须”发送或请求纯文本凭据时使用TLS/SSL进行更改。此更改影响“明文”签名方法的任何使用，以及请求临时凭据（第2.1节）和获取令牌凭据（第2.3节）。
o Adjusted nonce language to indicate it is unique per token/ timestamp/client combination.
o 调整了nonce语言，以表明它在每个令牌/时间戳/客户端组合中是唯一的。
o Removed the requirement for timestamps to be equal to or greater than the timestamp used in the previous request.
o 删除了时间戳等于或大于上一个请求中使用的时间戳的要求。
o Changed the nonce and timestamp parameters to OPTIONAL when using the "PLAINTEXT" signature method.
o 使用“明文”签名方法时，将nonce和timestamp参数更改为可选。
o Extended signature base string coverage that includes "application/x-www-form-urlencoded" entity-body parameters when the HTTP method used is other than "POST" and URI query parameters when the HTTP method used is other than "GET".
o 扩展的签名基本字符串覆盖范围，包括当使用的HTTP方法不是“POST”时的“application/x-www-form-urlencoded”实体体参数，以及当使用的HTTP方法不是“GET”时的URI查询参数。
o Incorporated corrections to the instructions in each signature method to encode the signature value before inserting it into the "oauth_signature" parameter, removing errors that would have caused double-encoded values.
o 在将签名值插入“oauth_signature”参数之前，对每个签名方法中的指令进行修正，以对签名值进行编码，从而消除可能导致双重编码值的错误。
o Allowed omitting the "oauth_token" parameter when empty.
o 允许在为空时省略“oauth_token”参数。
o Permitted sending requests for temporary credentials with an empty "oauth_token" parameter.
o 允许使用空的“oauth_令牌”参数发送临时凭据请求。
o Removed the restrictions from defining additional "oauth_" parameters.
o 删除了定义其他“oauth_3;”参数的限制。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[W3C.REC-html40-19980424] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.0 Specification", World Wide Web Consortium Recommendation REC-html40-19980424, April 1998, <http://www.w3.org/TR/1998/REC-html40-19980424>.
[W3C.REC-html40-19980424]Hors，A.，Raggett，D.，和I.Jacobs，“HTML 4.0规范”，万维网联盟建议REC-html40-19980424，1998年4月<http://www.w3.org/TR/1998/REC-html40-19980424>.
[NIST_SHA-1Comments] Burr, W., "NIST Comments on Cryptanalytic Attacks on SHA-1", <http://csrc.nist.gov/groups/ST/hash/statement.html>.
[NIST_SHA-1意见]Burr，W.，“NIST对SHA-1密码分析攻击的评论”<http://csrc.nist.gov/groups/ST/hash/statement.html>.
[OAuthCore1.0_RevisionA] OAuth Community, "OAuth Core 1.0 Revision A", <http://oauth.net/core/1.0a>.
[OAuthCore1.0修订版A]OAuth社区，“OAuthCore1.0修订版A”<http://oauth.net/core/1.0a>.
Author's Address
作者地址
Eran Hammer-Lahav (editor)
埃兰·哈默·拉哈夫（编辑）
EMail: eran@hueniverse.com
URI: http://hueniverse.com
EMail: eran@hueniverse.com
URI: http://hueniverse.com