[要約] RFC 5849はOAuth 1.0プロトコルに関する仕様書であり、OAuthの認証と認可のためのプロトコルを定義しています。目的は、クライアントアプリケーションがユーザーのリソースにアクセスするための安全な方法を提供することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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プロトコルは、保護されたリソースへの委任アクセスを可能にするという一般的な問題を解決したいと考えていたさまざまなWebサイトやその他のインターネットサービスの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は、従来のクライアント/サーバー認証モデルにリソース所有者という3番目の役割を導入します。 OAuthモデルでは、クライアント（リソースの所有者ではないが、その代わりに活動しています）は、リソースの所有者によって制御されているがサーバーによってホストされているリソースへのアクセスを要求します。さらに、OAuthを使用すると、サーバーはリソース所有者の承認だけでなく、要求を行っているクライアントのIDも確認できます。
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.
この仕様は2つの部分で構成されています。最初の部分では、サーバーで直接認証し、認証方法で使用するためにトークンをクライアントにプロビジョニングすることにより、エンドユーザーがリソースへのクライアントアクセスを承認するためのリダイレクトベースのユーザーエージェントプロセスを定義します。 2番目の部分は、2つの資格情報セットを使用して認証済みHTTP [RFC2616]要求を行う方法を定義します。1つは要求を行うクライアントを識別し、もう1つは要求に代わってリソース所有者を識別します。
The use of OAuth with any transport protocol other than [RFC2616] is undefined.
[RFC2616]以外のトランスポートプロトコルでのOAuthの使用は定義されていません。
client An HTTP client (per [RFC2616]) capable of making OAuth-authenticated requests (Section 3).
client（[RFC2616]による）OAuthで認証されたリクエストを行うことができるHTTPクライアント（セクション3）。
server An HTTP server (per [RFC2616]) capable of accepting OAuth-authenticated requests (Section 3).
server（[RFC2616]による）OAuthで認証されたリクエストを受け入れることができるHTTPサーバー（セクション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は、クライアント、一時、およびトークンの3つの資格情報クラスを定義します。これらは、それぞれ、要求、許可要求、およびアクセス許可を行うクライアントの識別と認証に使用されます。
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.
ジェーン（リソース所有者）は最近、プライベート休暇の写真（保護されたリソース）を写真共有サイト 'photos.example.net'（サーバー）にアップロードしました。彼女は「printer.example.com」ウェブサイト（クライアント）を使用して、これらの写真の1つを印刷したいと考えています。通常、ジェーンはユーザー名とパスワードを使用して「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:
ただし、ジェーンは自分のユーザー名とパスワードを、写真を印刷するためにアクセスする必要がある「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: Temporary Credential Request https://photos.example.net/initiate
「printer.example.com」Webサイトは、「HMAC-SHA1」署名方式を使用する「photos.example.net」APIドキュメントにリストされているプロトコルエンドポイントを使用するようにアプリケーションを設定しました。一時的な認証情報リクエストhttps：// photos.example.net/initiate
Resource Owner Authorization URI:
https://photos.example.net/authorize
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"
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 Content-Type：application / x-www-form-urlencoded
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03& oauth_callback_confirmed=true
oauth_token = hh5s93j4hdidpola＆oauth_token_secret = hdhd0244k9j7ao03＆oauth_callback_confirmed = 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:
クライアントはジェーンのユーザーエージェントをサーバーのリソース所有者承認エンドポイントにリダイレクトし、ジェーンのプライベート写真へのアクセスに関する承認を取得します。
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):
サーバーはジェーンにユーザー名とパスワードを使用してサインインするように要求し、成功した場合は、「printer.example.com」にプライベート写真へのアクセスを許可することを承認するように要求します。ジェーンは要求を承認し、ユーザーエージェントは前の要求でクライアントによって提供されたコールバックURIにリダイレクトされます（改行は表示のみを目的としています）。
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):
コールバック要求は、ジェーンが承認プロセスを完了したことをクライアントに通知します。次に、クライアントは、一時的な資格情報を使用して、一連のトークン資格情報を（安全なトランスポート層セキュリティ（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"
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 Content-Type：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"
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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はトークンを使用して、リソース所有者によってクライアントに付与された承認を表します。通常、トークンの資格情報は、リソース所有者のIDを認証した後（通常はユーザー名とパスワードを使用）、サーバーがリソース所有者の要求に応じて発行します。
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つ定義します。このリダイレクトベースの認証方法には、3つのステップが含まれます。
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.
サーバーは、トークンの資格情報を取得するために一度使用された後、一時的な資格情報を取り消す必要があります。一時的な認証情報には有効期限があることをお勧めします。サーバーは、リソース所有者がクライアントに発行された後にトークン資格情報を取り消せるようにする必要があります（SHOULD）。
In order for the client to perform these steps, the server needs to advertise the URIs of the following three endpoints:
クライアントがこれらの手順を実行するには、サーバーは次の3つのエンドポイントの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.
サーバーによってアドバタイズされる3つのURIには、[RFC3986]、セクション3で定義されたクエリコンポーネントが含まれる場合がありますが、存在する場合、追加されたプロトコルパラメータとの競合を避けるため、「oauth_」プレフィックスで始まるパラメータをクエリに含めてはなりません（MUST NOT）。使用時の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.
サーバーがその3つのエンドポイントを通知および文書化する方法は、この仕様の範囲外です。クライアントは、この仕様では未定義のままになっているトークンやその他のサーバー生成値のサイズについての想定を避ける必要があります。さらに、プロトコルパラメータには、送信時にエンコードが必要な値が含まれる場合があります。クライアントとサーバーは、それらの値の可能な範囲について仮定を行うべきではありません。
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"リクエストをTemporary Credential Requestエンドポイントに送信することにより、サーバーから一時的な認証情報のセットを取得します（サーバーがクライアントに使用する別のHTTPリクエストメソッドを通知しない限り）。クライアントは、次のREQUIREDパラメータをリクエストに（他のプロトコルパラメータに加えて、同じパラメータ送信メソッドを使用して）追加することにより、リクエスト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_callback：リソース所有者の承認手順（セクション2.2）が完了したときにサーバーがリソース所有者をリダイレクトする絶対URI。クライアントがコールバックを受信できない場合、または他の方法でコールバックURIが確立されている場合は、パラメータ値を「oob」（大文字と小文字を区別）に設定して、帯域外構成を示す必要があります。
Servers MAY specify additional parameters.
サーバーは追加のパラメーターを指定してもよい（MAY）。
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"プロトコルパラメータをリクエストから省略してもよく（MAY）、空の文字列をトークンの秘密の値として使用しなければなりません（MUST）。
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やSecure Socket Layer（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"
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ステータスコード（OK）を使用して、HTTP応答の本文に含まれます。
The response contains the following REQUIRED parameters:
応答には、以下の必須パラメーターが含まれています。
oauth_token The temporary credentials identifier.
oauth_token一時的な認証情報識別子。
oauth_token_secret The temporary credentials shared-secret.
oauth_token_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_confirmedが存在し、「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.
パラメーター名に「トークン」という用語が含まれていても、これらの資格情報はトークン資格情報ではなく、トークン資格情報と同様の方法で次の2つのステップで使用されることに注意してください。
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 Content-Type：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_confirmed = 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: 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.
クライアントがサーバーから一連のトークン資格情報を要求する前に、クライアントはユーザーをサーバーに送信して要求を承認する必要があります。クライアントは、リソース所有者承認エンドポイントURIに次の必須クエリパラメータを追加して、リクエストURIを作成します。oauth_tokenセクション2.1で取得した一時的な資格情報識別子 "oauth_token"パラメータ。サーバーは、このパラメーターをオプションとして宣言する場合があります。その場合、サーバーは、リソース所有者が他の方法で識別子を示す方法を提供する必要があります。
Servers MAY specify additional parameters.
サーバーは追加のパラメーターを指定してもよい（MAY）。
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
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などのセキュアチャネルを使用するかどうかなど、サーバーが承認リクエストを処理する方法は、この仕様の範囲を超えています。ただし、サーバーは最初にリソース所有者のIDを確認する必要があります。
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.
リソース所有者に要求されたアクセスを承認するように要求するとき、サーバーは、一時的な資格情報とクライアントIDの関連付けに基づいて、アクセスを要求しているクライアントに関する情報をリソース所有者に提示する必要があります（SHOULD）。そのような情報を表示するとき、サーバーは情報が確認されたかどうかを示すべきです（SHOULD）。
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.
リソース所有者から承認の決定を受け取った後、サーバーはリソース所有者をコールバックURIにリダイレクトします（コールバックURIが「oauth_callback」パラメーターまたは他の手段で提供されている場合）。
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_tokenクライアントから受信した一時的な認証情報識別子。
oauth_verifier The verification code.
oauth_verifier検証コード。
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
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を提供しなかった場合、サーバーは検証コードの値を表示し、認証が完了したことをクライアントに手動で通知するようにリソース所有者に指示する必要があります（SHOULD）。サーバーがクライアントが限定されたデバイスで実行されていることを知っている場合、検証者の値が手動入力に適していることを確認する必要があります。
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要求メソッドを通知しない限り）。クライアントは、次のREQUIREDパラメータをリクエストに（他のプロトコルパラメータに加えて、同じパラメータ送信メソッドを使用して）追加することにより、リクエストURIを構築します。
oauth_verifier The verification code received from the server in the previous step.
oauth_verifier前のステップでサーバーから受信した検証コード。
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"
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-urlencoded」コンテンツタイプと200ステータスコードを使用して、HTTPレスポンスの本文に含まれます。 （OK）。
The response contains the following REQUIRED parameters:
応答には、以下の必須パラメーターが含まれています。
oauth_token The token identifier.
oauth_tokenトークン識別子。
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 Content-Type：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つの資格情報セットを含めるように設計されたメソッドを提供します。クライアントは、リソース所有者に代わって認証済みリクエストを行う前に、リソース所有者によって承認されたトークンを取得する必要があります。セクション2は、クライアントがリソース所有者によって承認されたトークンを取得できる1つの方法を提供します。
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: 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.
1.クライアントは、（特に指定されていない限り）これらの必須の各プロトコルパラメーターに値を割り当てます。oauth_consumer_keyクライアント資格情報のID部分（ユーザー名と同じ）。パラメータ名は、仕様の以前のリビジョンで使用されていた非推奨の用語（コンシューマキー）を反映しており、下位互換性を維持するために保持されています。
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_tokenリクエストをリソース所有者に関連付けるために使用されるトークン値。リクエストがリソース所有者に関連付けられていない場合（利用可能なトークンがない場合）、クライアントはパラメーターを省略できます（MAY）。
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で定義されているタイムスタンプ値。 「PLAINTEXT」署名メソッドを使用する場合、パラメータは省略してもよい（MAY）。
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値。 「PLAINTEXT」署名メソッドを使用する場合、パラメータは省略してもよい（MAY）。
oauth_version OPTIONAL. If present, MUST be set to "1.0". Provides the version of the authentication process as defined in this specification.
oauth_versionオプション。存在する場合、「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_signature」パラメータの値を計算して割り当て、前のステップと同じ方法を使用してリクエストにパラメータを追加します。
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
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:
クライアントは、クライアント資格情報、トークン資格情報、現在のタイムスタンプ、一意に生成されたナンスを使用して、次のプロトコルパラメータに値を割り当て、「HMAC-SHA1」署名方式を使用することを示します。
oauth_consumer_key: 9djdj82h48djs9d2 oauth_token: kkk9d7dh3k39sjv7 oauth_signature_method: HMAC-SHA1 oauth_timestamp: 137131201 oauth_nonce: 7d8f3e4a
oauth_consumer_key：9djdj82h48djs9d2 oauth_token：kkk9d7dh3k39sjv7 oauth_signature_method：HMAC-SHA1 oauth_timestamp：137131201 oauth_nonce：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 = "Example"、oauth_consumer_key = "9djdj82h48djs9d2"、oauth_token = "kkk9d7dh3k39sjv7"、oauth_signature_method = "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_signature」パラメーターの値を計算し（クライアントシークレット「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"
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_signature"パラメータを介してクライアントから受信した値と比較します。
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レスポンスステータスコードで応答する必要があります（SHOULD）。サーバーは、リクエストの本文が拒否された理由の詳細を含めることができます。
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（不正なリクエスト）ステータスコードを返す必要があります。サーバーは、無効なクライアント資格情報、無効または期限切れのトークン、無効な署名、または無効または使用されたナンスを含むリクエストを受信すると、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」パラメータ内のものの2つの資格情報セットを含めることができます。サーバーがリクエストの信頼性を検証し、不正アクセスを防ぐために、クライアントはそれが資格情報の正当な所有者であることを証明する必要があります。これは、資格情報の各セットの共有秘密（または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は、クライアントが資格情報の正当な所有権を証明するための3つの方法を提供します：「HMAC-SHA1」、「RSA-SHA1」、および「PLAINTEXT」。これらのメソッドは、 "PLAINTEXT"が署名を含まない場合でも、一般に署名メソッドと呼ばれます。さらに、「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_signature」パラメーターを除いて、要求またはそのパラメーターを変更しません。
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 "Host"リクエストヘッダーフィールドで宣言された権限。
o The path and query components of the request resource URI.
o 要求リソースURIのパスおよびクエリコンポーネント。
o The protocol parameters excluding the "oauth_signature".
o 「oauth_signature」を除くプロトコルパラメータ。
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.6）、セクション3.4.1.3.2で正規化された要求パラメーター。
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"
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％2Fexample.com％2Frequest＆a2％3Dr％2520b％26a3％3D2％2520q％26a3％3Da％26b5％3D％253D％25253D％26c％2540％3D％26c2％3D％26c2％3D％26oauth_consumer_ key％3D9dddd9dno9h9ddjdhdhdh88h2 ％3D7d8f3e4a％26oauth_signature_m ethod％3DHMAC-SHA1％26oauth_timestamp％3D137131201％26oauth_token％3Dkkk 9d7dh3k39sjv7
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リクエストの「Host」ヘッダーフィールドの内容と一致する必要があります。
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
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
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の「Authorization」ヘッダーフィールド（セクション3.5.1）（存在する場合）。ヘッダーのコンテンツは、「レルム」パラメーターが存在する場合はそれを除いて、名前と値のペアのリストに解析されます。パラメータ値は、セクション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_signature」パラメータは、存在する場合、署名ベース文字列から除外する必要があります。リクエストに明示的に含まれていないパラメーターは、署名のベース文字列から除外する必要があります（たとえば、省略した場合は「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"
c2&a3=2+q
c2＆a3 = 2 + q
contains the following (fully decoded) parameters used in the signature base 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 |
+------------------------+------------------+
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コード32）を表すための「+」文字（ASCIIコード43）の使用は除外されていますが、この方法は「 application / x-www-form-urlencoded "エンコードされた値であり、「a3」パラメータインスタンスの1つで示されるように、適切にデコードする必要があります（「a3」パラメータはこのリクエストで2回使用されます）。
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. パラメーターは、バイト値の昇順を使用して、名前でソートされます。 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）を使用して、1つの文字列に連結されます。
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 |
+------------------------+------------------+
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 |
+------------------------+------------------+
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 |
+-------------------------------------+
and concatenated together into a single string (line breaks are for display purposes only):
そして、1つの文字列に連結されます（改行は表示のみを目的としています）：
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]に従ってbase64でエンコードされた後、ダイジェストを使用して「oauth_signature」プロトコルパラメータの値を設定します。セクション6.8。
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（別名PKCS＃1）で定義されているRSASSA-PKCS1-v1_5署名アルゴリズムを使用し、EMSA-PKCS1-v1_5のハッシュ関数としてSHA-1を使用します。このメソッドを使用するには、クライアントは、RSA公開鍵を含むサーバーで（この仕様の範囲を超える方法で）クライアント資格情報を確立している必要があります。
The signature base string is signed using the client's RSA private key per [RFC3447], Section 8.2.1:
署名ベース文字列は、[RFC3447]のクライアントのRSA秘密鍵を使用して署名されています。セクション8.2.1：
S = RSASSA-PKCS1-V1_5-SIGN (K, M)
S = RSASSA-PKCS1-V1_5-SIGN（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_signature」プロトコルパラメータの値を設定するために使用される結果の署名です。
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-VERIFY（（n、e）、M、S）
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_signature」プロトコルパラメータのオクテット文字列値に設定されます。
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.
「PLAINTEXT」メソッドは、署名アルゴリズムを採用していません。 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_」接頭辞を使用するその他のパラメータは、優先順位の高いものから順に、次の場所の1つだけを使用してリクエストに含める必要があります。
1. The HTTP "Authorization" header field as described in Section 3.5.1.
1. セクション3.5.1で説明されているHTTP "Authorization"ヘッダーフィールド。
2. The HTTP request entity-body as described in Section 3.5.2.
2. セクション3.5.2で説明されているHTTPリクエストのエンティティ本体。
3. The HTTP request URI query as described in Section 3.5.3.
3. セクション3.5.3で説明されているHTTPリクエストURIクエリ。
In addition to these three methods, future extensions MAY define other methods for including protocol parameters in the request.
これらの3つのメソッドに加えて、将来の拡張では、リクエストにプロトコルパラメータを含めるための他のメソッドを定義する場合があります。
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]で定義されているように、auth-scheme名を "OAuth"（大文字と小文字を区別しない）に設定して、HTTP "Authorization"ヘッダーフィールドを使用して送信できます。
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 = "wOJIO9A2W5mFwdidDtime3d6d6dd3d3dd3d3d3d60d3d6d3dd3dd3d3dd3d3dd3d3d4d64dauth3d6e3e0e0e0e0e0c0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0b 、oauth_version = "1.0"
Protocol parameters SHALL be included in the "Authorization" header field as follows:
プロトコルパラメータは、次のように "Authorization"ヘッダーフィールドに含める必要があります。
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. パラメータは「、」文字（ASCIIコード44）と[RFC2617]によるオプションの線形空白で区切られます。
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" auth-schemeのサポートを示してもよい（MAY）。 [RFC2617]によると、このような応答には追加のHTTP "WWW-Authenticate"ヘッダーフィールドが含まれる場合があります：
For example:
例えば：
WWW-Authenticate: OAuth realm="http://server.example.com/"
The realm parameter defines a protection realm per [RFC2617], Section 1.2.
realmパラメータは、[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
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）で適切に区切って、リクエスト固有のパラメータの後に追加する必要があります（SHOULD）。
Protocol parameters can be transmitted by being added to the HTTP request URI as a query parameter as defined by [RFC3986], Section 3.
プロトコルパラメータは、[RFC3986]のセクション3で定義されているクエリパラメータとしてHTTPリクエストURIに追加することで送信できます。
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
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）で適切に区切って追加する必要があります（SHOULD）。
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（ALPHA、DIGIT、「-」、「。」、「_」、「〜」）で定義されている予約されていない文字セットの文字はエンコードしないでください。
* All other characters MUST be encoded.
* 他のすべての文字はエンコードする必要があります。
* The two hexadecimal characters used to represent encoded characters MUST be uppercase.
* エンコードされた文字を表すために使用される2つの16進文字は大文字でなければなりません。
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開発フレームワークによって提供されるパーセントエンコード関数とは異なる場合があります（たとえば、異なる文字をエンコードする、小文字の16進文字を使用する）。
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.
このプロトコルと同様のプロトコルを広く展開すると、リソースの所有者は、パスワードの入力を求められるWebサイトにリダイレクトされる習慣に慣れることができなくなる可能性があります。リソース所有者が資格情報を入力する前にこれらのWebサイトの信頼性を確認するように注意していない場合、攻撃者がこの手法を悪用してリソース所有者のパスワードを盗む可能性があります。
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.
サーバーは、フィッシング攻撃がもたらすリスクについてリソース所有者を教育し、リソース所有者がサイトの信頼性を簡単に確認できるメカニズムを提供する必要があります。クライアント開発者は、ユーザーエージェント（別のウィンドウ、埋め込みなど）との相互作用のセキュリティへの影響、およびサーバーWebサイトの信頼性を確認するエンドユーザーの機能を考慮する必要があります。
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.
たとえば、共有シークレットが2週間有効である場合、サーバーは、共有シークレットを2週間未満で回復するブルートフォース攻撃を開始できないようにする必要があります。もちろん、サーバーは注意を怠って誤解を招き、妥当な限り長い秘密を使用するよう求められます。
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.
この仕様には、サーバーに対するリソース枯渇攻撃を可能にする可能性のあるいくつかの機能が含まれています。たとえば、このプロトコルでは、サーバーが使用済みナンスを追跡する必要があります。攻撃者が多くのノンスをすばやく使用できる場合、それらを追跡するために必要なリソースが利用可能な容量を使い果たす可能性があります。また、このプロトコルでは、着信要求の署名を検証するために、サーバーにコストがかかる可能性のある計算を実行するよう要求できます。攻撃者はこれを悪用して、サーバーに大量の無効な要求を送信することにより、サービス拒否攻撃を実行する可能性があります。
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には、衝突攻撃に対する耐性を大幅に低下させる多くの暗号の弱点があることが示されています。これらの弱点はハッシュベースのメッセージ認証コード（HMAC）でのSHA-1の使用に影響を与えないようであり、「HMAC-SHA1」署名方式には影響しないはずですが、「RSA-SHA1」の使用に影響する可能性があります署名方法。 NISTは、2010年までにデジタル署名でのSHA-1の使用を段階的に廃止することを発表しました[NIST_SHA-1Comments]。
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リクエストは、Webサイトが信頼するか認証したユーザーから送信されます。承認の承認に対する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 Revision 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によって編集され、以下によって作成されました。ハンマーラハ、ベンローリー、クリスメッシーナ、ジョンパンツァー、サムクィグリー、デビッドレコートン、エランサンドラー、ジョナサンサージェント、トッドシーリング、ブライアンスレシンスキー、アンディスミス。
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.0_RevisionA]に加えられた以下の変更が含まれています。
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を使用してSHOULDからMUSTに変更しました。この変更は、「PLAINTEXT」署名メソッドの使用、および一時的な認証情報の要求（2.1）とトークン認証情報の取得（2.3）に影響します。
o Adjusted nonce language to indicate it is unique per token/ timestamp/client combination.
o トークン/タイムスタンプ/クライアントの組み合わせごとに一意であることを示すようにナンス言語を調整しました。
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 「PLAINTEXT」署名メソッドを使用する場合、ナンスとタイムスタンプのパラメーターをオプションに変更しました。
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_token"パラメータを使用した一時的な認証情報の送信リクエストが許可されました。
o Removed the restrictions from defining additional "oauth_" parameters.
o 追加の「oauth_」パラメーターの定義から制限を削除しました。
[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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年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：Keyed-Hashing for Message Authentication」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-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.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、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、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 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、「Uniform Resource Identifier（URI）：Generic Syntax」、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仕様」、World Wide Web Consortium Recommendation 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-1Comments] Burr、W。、「SHA-1に対する暗号解読攻撃に関するNISTコメント」、<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_RevisionA] OAuthコミュニティ、「OAuth Core 1.0 Revision A」、<http://oauth.net/core/1.0a>。
Author's Address
著者のアドレス
Eran Hammer-Lahav (editor)
エラン・ハマー=ラハフ（編集者）
EMail: eran@hueniverse.com
URI: http://hueniverse.com