December 4, 2007
The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.
OAuthプロトコルはウェブサイトかアプリケーション等(= Consumer)を、ConsumerにService Providerのクレデンシャルを開示する事をUserに要求する事無く、APIによるウェブサービス(= Service Provider)からの保護されたリソースにアクセスする事を可能にします。
An example use case is allowing printing service printer.example.com (the Consumer), to access private photos stored on photos.example.net (the Service Provider) without requiring Users to provide their photos.example.net credentials to printer.example.com.
ユースケースの例えの1つは、"photos.example.net"のクレデンシャルを"printer.example.com"に提供する事をユーザーに要求する事無く、"photos.example.net"(Service Providerです)上のプライベートな写真の記録にアクセスする事を、印刷サービス"printer.example.com"(Consumerです)に許可する事です。
OAuth does not require a specific user interface or interaction pattern, nor does it specify how Service Providers authenticate Users, making the protocol ideally suited for cases where authentication credentials are unavailable to the Consumer, such as with OpenID.
OAuthは特定のユーザーインターフェースやインタラクションパターンを要求しませんが、Service Providerがユーザを認証する方法も指定せず、OpenIDのように認証クレデンシャルがConsumerにとって利用できないケースについてプロトコルが理論上は適する様にします。
OAuth aims to unify the experience and implementation of delegated web service authentication into a single, community-driven protocol. OAuth builds on existing protocols and best practices that have been independently implemented by various websites. An open standard, supported by large and small providers alike, promotes a consistent and trusted experience for both application developers and the users of those applications.
OAuthは、委任されたウェブサービス認証を1つにして、コミュニティ主導のプロトコルに経験と手段を統一する事をねらいます。OAuthは既存のプロトコルと様々なウェブサイトによって独立して実装されてきた事のベストプラクティスを足場にます。公開標準は、大小のプロバイダーによって等しくサポートされ、アプリケーション開発者達とそれらアプリケーションの利用者両方のために、安定と信頼される経験を促進します。
1.
Authors (著者)
2.
Notation and Conventions (表記と慣例)
3.
Definitions (定義)
4.
Documentation and Registration (文書化と記録)
4.1.
Request URLs
4.2.
Service Providers
4.3.
Consumers
5.
Parameters (パラメータ)
5.1.
Parameter Encoding (パラメータエンコーディング)
5.2.
Consumer Request Parameters (コンシューマリクエストパラメータ)
5.3.
Service Provider Response Parameters (サービスプロバイダーレスポンスパラメータ)
5.4.
OAuth HTTP Authorization Scheme (OAuth HTTP 認可スキーム)
6.
Authenticating with OAuth (OAuthによる認証)
6.1.
Obtaining an Unauthorized Request Token(認可されていないリクエストの獲得)
6.2.
Obtaining User Authorization (ユーザーの認可の獲得)
6.3.
Obtaining an Access Token (アクセストークンの獲得)
7.
Accessing Protected Resources (保護リソースへのアクセス)
8.
Nonce and Timestamp (nonceとタイムスタンプ)
9.
Signing Requests (リクエストへの署名)
9.1.
Signature Base String (署名ベース文字列)
9.2.
HMAC-SHA1
9.3.
RSA-SHA1
9.4.
PLAINTEXT
10.
HTTP Response Codes (HTTPレスポンスコード)
Appendix A.
Appendix A - Protocol Example (プロトコルの例)
Appendix A.1.
Documentation and Registration
Appendix A.2.
Obtaining a Request Token (Request Tokenの取得)
Appendix A.3.
Requesting User Authorization (ユーザー認可のリクエスト)
Appendix A.4.
Obtaining an Access Token (Access Tokenの取得)
Appendix A.5.
Accessing Protected Resources (Protected Resourceへのアクセス)
Appendix B.
Security Considerations (セキュリティ考察)
Appendix B.1.
Credentials and Token Exchange (クレデンシャルとトークンの交換)
Appendix B.2.
PLAINTEXT Signature Method (PLAINTEXT署名メソッド)
Appendix B.3.
Confidentiality of Requests (リクエストの保持/機密性)
Appendix B.4.
Spoofing by Counterfeit Servers (偽造サービスによるスプーフィング)
Appendix B.5.
Proxying and Caching of Authenticated Content (認証済みコンテントのキャッシュとプロクシ)
Appendix B.6.
Plaintext Storage of Credentials (クレデンシャルのプレーンテキスト記憶)
Appendix B.7.
Secrecy of the Consumer Secret (Consumer Secretのセキュリティ)
Appendix B.8.
Phishing Attacks (フィッシング攻撃)
Appendix B.9.
Scoping of Access Requests (アクセスリクエストの品定め)
Appendix B.10.
Entropy of Secrets (Secretのエントロピー)
Appendix B.11.
Denial of Service / Resource Exhaustion Attacks (リソース消耗攻撃)
Appendix B.12.
Cryptographic Attacks (暗号の攻撃)
Appendix B.13.
Signature Base String Compatibility (署名ベース文字列互換性)
11.
Reference (参照)s
§
Author’s Address (著者のアドレス)
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] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .).
- Service Provider:
- A web application that allows access via OAuth.
OAuthを使ったアクセスを許可するウェブアプリケーション。
- User:
- An individual who has an account with the Service Provider.
Service Providerにアカウントを持っている個人。
- Consumer:
- A website or application that uses OAuth to access the Service Provider on behalf of the User.
Userに代わってService ProviderにアクセスするためにOAuthを使うウェブサイトかアプリケーション。
- Protected Resource(s):
- Data controlled by the Service Provider, which the Consumer can access through authentication.
Consumerが認証によってアクセスできる、Service Providerによって管理されるデータ。
- Consumer Developer:
- An individual or organization that implements a Consumer.
Consumerを実装する個人か団体。
- Consumer Key:
- A value used by the Consumer to identify itself to the Service Provider.
自身をService Providerで識別するためのConsumerによって使われる値。
- Consumer Secret:
- A secret used by the Consumer to establish ownership of the Consumer Key.
Consumer Keyの所有権を証明するためにConsumerによって使われる秘密。
- Request Token:
- A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token.
Userから認可を得るためにConsumerによって使われる値で、Access Tokenと交換される。
- Access Token:
- A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the User’s Service Provider credentials.
Userの代わりにProtected Resourceへのアクセス方法を手に入れるために、UserのService Providerクレデンシャルの代わりとして、Consumerによって使われる値。
- Token Secret:
- A secret used by the Consumer to establish ownership of a given Token.
与えられるトークンの所有権を証明する為にConsumerによって使われる秘密。
- OAuth Protocol Parameters:
- Parameters with names beginning with oauth_.
oauth_で始まる名前を持つパラメータ。
OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources).
OAuthは、Consumer Keyと、Service ProviderのためにConsumerをしっかりと認証する(Userとは対照的に)Consumer Secretを含みます。Consumer固有の身分証明書はService ProviderにConsumerのためのさまざまなアクセスレベル(例えばリソースへの非抑圧アクセスなど)を許可します。
Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).
Consumer SecreteがConsumerとService Provider以外の誰にも得られないと分かっているのでない限り、Service ProviderはConsumer識別子を立証する為の方法としてConsumer Secretを信頼すべきではありません(SHOULD NOT)。Consumer Secretは空文字列(例えばConsumerの立証が必要でない時か、立証がRSAのような他の意味で達成されている時)かもしれません(MAY)。
OAuth defines three request URLs:
OAuthは3つのリクエストURLを定義します:
- Request Token URL:
- The URL used to obtain an unauthorized Request Token, described in Section 6.1 (Obtaining an Unauthorized Request Token).
> セクション 6.1 (Obtaining an Unauthorized Request Token)で説明される、認可されていないRequest Tokenを取得する為に使われるURL。
- User Authorization URL:
- The URL used to obtain User authorization for Consumer access, described in Section 6.2 (Obtaining User Authorization).
セクション 6.2 (Obtaining User Authorization)で説明される、Consumerのアクセスについてユーザーの認可を取得する為のURL。
- Access Token URL:
- The URL used to exchange the User-authorized Request Token for an Access Token, described in Section 6.3 (Obtaining an Access Token).
セクション 6.3 (Obtaining an Access Token)で説明される、ユーザーが認可したリクエストをAccess Tokenと交換する為に使われるURL。
The three URLs MUST include scheme, authority, and path, and MAY include query and fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3. The request URL query MUST NOT contain any OAuth Protocol Parameters. For example:
3つのURLは、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション3で定義されるような、スキームとオーソリティとパス含まなければならず(MUST)、クエリとフラグメントを含むかもしれません(MAY)。リクエストURLのクエリは何かしらのOAuth Protocol Parameterを含んではなりません(MUST NOT)。例えば:
http://sp.example.com/authorize
The Service Provider’s responsibility is to enable Consumer Developers to establish a Consumer Key and Consumer Secret. The process and requirements for provisioning these are entirely up to the Service Providers.
Service Providerの義務はConsumer DevelopersにConsumer KeyとConsumer Secretを証明出来る様にする事です。これらを提供することに関するプロセスと要件は完全にService Providerの義務です。
The Service Provider’s documentation includes:
Service Providerの文書は以下を含みます:
OAuthリクエストを作るときにConsumerが使うだろうURLs (Request URLs)と、Request Token URLとAccess Token URLで使われるHTTPメソッド(例えば、GETやPOSTや他)。
Service Providerによってサポートされる署名方法。
Service ProviderがTokenを手に入れる為に要求する何かしらの追加リクエストパラメータ。Service Provider特有のパラメータはoauth_で始まってはなりません(MUST NOT)。
The Consumer Developer MUST establish a Consumer Key and a Consumer Secret with the Service Provider. The Consumer Developer MAY also be required to provide additional information to the Service Provider upon registration.
Consumer DeveloperはService Providerに関してConsumer KeyとConsumer Secretを証明しなければなりません(MUST)。Consumer Developerは登録でのService Providerへの追加情報の提供もまた要求されるかもしれません(MAY)。
OAuth Protocol Parameter names and values are case sensitive. Each OAuth Protocol Parameters MUST NOT appear more than once per request, and are REQUIRED unless otherwise noted.
OAuth Protocol Parameterの名前と値はケースセンシティブです。それぞれのOAuth Protocol Parameterは各リクエストで1度以上現れてはならず(MUST NOT)、特別に明記されない限り必須です(REQUIRED)。
All parameter names and values are escaped using the [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) percent-encoding (%xx) mechanism. Characters not in the unreserved character set ([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 2.3) MUST be encoded. Characters in the unreserved character set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. Text names and values MUST be encoded as UTF-8 octets before percent-encoding them per [RFC3629] (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .).
全てのパラメータの名前と値は[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のパーセントエンコーディング(%xx)のメカニズムを使ってエスケープされます。非予約文字集合の中にない文字([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション2.3)はエンコードされなければなりません(MUST)。 非予約文字集合の中の文字はエンコードされてはなりません(MUST NOT)。エンコーディングの中の16進文字は大文字でなければなりません(MUST)。テキストの名前と値は[RFC3629] (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .)に従ったパーセントエンコーディングの前にUTF-8オクテットとしてエンコードされなければなりません(MUST)。
unreserved = ALPHA, DIGIT, '-', '.', '_', '~'
OAuth Protocol Parameters are sent from the Consumer to the Service Provider in one of three methods, in order of decreasing preference:
OAuth Protocol Parameterは、優先権を減少させながらふさわしい、3つの方法のうちの1つでConsumerからService Providerに送られます:
OAuthのHTTP認可スキーム(OAuth HTTP Authorization Scheme) (OAuth HTTP Authorization Scheme)で定義されるようなHTTPのAuthorizationヘッダの中。
content-typeにapplication/x-www-form-urlencodedを使ったHTTPのPOSTリクエストボディとして。
クエリ部分としてURLに追加される([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション3で定義されるような)。
In addition to these defined methods, future extensions may describe alternate methods for sending the OAuth Protocol Parameters. The methods for sending other request parameters are left undefined, but SHOULD NOT use the OAuth HTTP Authorization Scheme (OAuth HTTP Authorization Scheme) header.
これらの定義された方法に追加で、将来的な拡張がOAuth Protocol Parameterを送るための代替方法を表現するかもしれません。他のリクエストパラメータを送る為の方法はまだ未定義ですが、OAuthのHTTP認可スキーム(OAuth HTTP Authorization Scheme) (OAuth HTTP Authorization Scheme)ヘッダを使うべきではありません(SHOULD NOT)。
Response parameters are sent by the Service Provider to return Tokens and other information to the Consumer in the HTTP response body. The parameter names and values are first encoded as per Parameter Encoding (Parameter Encoding), and concatenated with the ‘&’ character (ASCII code 38) as defined in [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) Section 2.1. For example:
レスポンスパラメータはConsumerにTokenと他の情報を返す為にHTTPレスポンスボディでService Providerによって送られます。パラメータの名前と値はまず パラメータエンコーディング(Parameter Encoding) (Parameter Encoding)に従い、そして[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション2.1で定義されるように"&"の文字(ASCIIコード38)を使って連結されます。例えば:
oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b
This section defines an [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .) extension to support OAuth. It uses the standard HTTP Authorization and WWW-Authenticate headers to pass OAuth Protocol Parameters.
このセクションはOAuthをサポートする為の[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)の拡張を定義します。OAuth Protocol Parameterを受け取る為に標準のHTTPのAuthorizationヘッダとWWW-Authenticateヘッダを使います。
It is RECOMMENDED that Service Providers accept the HTTP Authorization header. Consumers SHOULD be able to send OAuth Protocol Parameters in the OAuth Authorization header.
Service ProviderはHTTPのAuthorizationヘッダを受け入れる事が推奨されます(RECOMMENDED)。Consumerは OAuthのAuthorizationヘッダの中でOAuth Protocol Parameterを送る事ができるべきです(SHOULD)。
The extension auth-scheme (as defined by [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)) is OAuth and is case-insensitive.
拡張auth-scheme([RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)で定義される)はOAuthでケースインセンシティブです。
The OAuth Protocol Parameters are sent in the Authorization header the following way:
OAuth Protocol Parameterは次に述べる方法でAuthorizationヘッダの中で送られます:
パラメータの名前と値はパラメータエンコーディング(Parameter Encoding) (Parameter Encoding)に従ってエンコードされます。
それぞれのパラメータで、その名前の直後には‘=’文字(ASCIIコード61)、‘”’文字(ASCIIコード34)、そのパラメータの値(空かもしれない(MAY))、‘”’文字(ASCIIコード34)と続きます。
パラメータは、[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)に従い、カンマ文字(ASCIIコード44)と任意(OPTIONAL)の連続する空白文字によって区切られます。
任意(OPTIONAL)のrealmパラメータは[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)のセクション1.2に従って追加されて解釈されます。
For example:
例:
Authorization: OAuth realm="http://sp.example.com/",
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"
Service Providers MAY indicate their support for the extension by returning the OAuth HTTP WWW-Authenticate header upon Consumer requests for Protected Resources. As per [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .) such a response MAY include additional HTTP WWW-Authenticate headers:
Service Providerは、Protected Resourceに関するConsumerリクエストに対してOAuthのHTTP WWW-Authenticateヘッダを返す事によって、それらがサポートする拡張を示すかもしれません(MAY)。[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)に従ったレスポンスは追加のHTTP WWW-Authenticateヘッダを含むかもしれません(MAY):
For example:
例:
WWW-Authenticate: OAuth realm="http://sp.example.com/"
The realm parameter defines a protection realm per [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .), section 1.2.
realmパラメータは[RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .)のセクション1.2に従って保護領域を定義します。
OAuth authentication is the process in which Users grant access to their Protected Resources without sharing their credentials with the Consumer. OAuth uses Tokens generated by the Service Provider instead of the User’s credentials in Protected Resources requests. The process uses two Token types:
OAuth認証はUser達Consumerと彼らのクレデンシャルを共有する事無く彼らのProtected Resourceへのアクセスを認めるためのプロセスです。OAuthはProtected Resourceを要求する為にUserのクレデンシャルの代わりにService Providerによって生成されたTokenを使います。そのプロセスは2つのTokeyタイプを使います:
- Request Token:
- Used by the Consumer to ask the User to authorize access to the Protected Resources. The User-authorized Request Token is exchanged for an Access Token, MUST only be used once, and MUST NOT be used for any other purpose. It is RECOMMENDED that Request Tokens have a limited lifetime.
UserにProtected Resourceへのアクセスの認可を求める為にConsumerによって使われます。Userが認可したRequest TokenはAccess Tokenと交換され、1度しか使われてはならず(MUST)、他のいかなる目的のために使われてはなりません(MUST NOT)。Request Tokenは制限された生存時間を持つ事が推奨されます(RECOMMENDED)。
- Access Token:
- Used by the Consumer to access the Protected Resources on behalf of the User. Access Tokens MAY limit access to certain Protected Resources, and MAY have a limited lifetime. Service Providers SHOULD allow Users to revoke Access Tokens. Only the Access Token SHALL be used to access the Protect Resources.
Userに代わってProtected Resourceにアクセスする為にConsumerによって使われます。Access Tokenは一定のProtected Resourceへのアクセスを制限するかもしれず(MAY)、制限された生存時間を持つかもしれません(MAY)。Service ProviderはUserにAccess Tokenを破棄する事を許可すべきです(SHOULD)。Access TokenはProtected Resourceにアクセスする為にのみ使われるものとします(SHALL)。
OAuth Authentication is done in three steps:
OAuth認証は3ステップを行います:
Consumerはまだ認可されていないRequest Tokenを取得します。
UserはそのReqeust Tokenを認可します。
ConsumerはRequest TokenをAccess Tokenと交換します。
The Consumer obtains an unauthorized Request Token by asking the Service Provider to issue a Token. The Request Token’s sole purpose is to receive User approval and can only be used to obtain an Access Token. The Request Token process goes as follows:
ConsumerはTokenの発行をService Providerに求める事で認可されていないRequest Tokenを取得します。Request Tokenの唯一の目的はUserの承認を受け取る事で、Access Tokenを取得する為にのみ使う事が出来ます。Request Tokenのプロセスは次に述べるものです:
To obtain a Request Token, the Consumer sends an HTTP request to the Service Provider’s Request Token URL. The Service Provider documentation specifies the HTTP method for this request, and HTTP POST is RECOMMENDED. The request MUST be signed and contains the following parameters:
Request Tokenを得る為に、ConsumerはHTTPリクエストをService ProviderのRequest Token URLに送ります。Service Provider文書はこのリクエストの為のHTTPメソッドを明記し、HTTP POSTが推奨されます(RECOMMENDED.)。そのリクエストは署名され次に続くパラメータを含まなければなりません(MUST)。
- oauth_consumer_key:
- The Consumer Key.
Consumer Keyです。
- oauth_signature_method:
- The signature method the Consumer used to sign the request.
Consumerがリクエストに署名する為に使った署名方法です。
- oauth_signature:
- The signature as defined in Signing Requests (Signing Requests).
リクエストの署名(Signing Requests) (Signing Requests)で定義される様な署名です。
- oauth_timestamp:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義される様なものです。
- oauth_nonce:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義される様なものです。
- oauth_version:
- OPTIONAL. If present, value MUST be 1.0 . Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. Service Providers’ response to non-1.0 value is left undefined.
任意です(OPTIONAL)。もし与えられたなら、値は1.0でなければなりません(MUST)。Service Providerは もしこのパラメータが与えられなかった場合はプロトコルバージョンが1.0であると仮定しなければなりません(MUST)。1.0という値ではないService Providerのレスポンスはまだ定義されていません。
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Service Providerによって定義される何か追加のパラメータです。
The Service Provider verifies the signature and Consumer Key. If successful, it generates a Request Token and Token Secret and returns them to the Consumer in the HTTP response body as defined in Service Provider Response Parameters (Service Provider Response Parameters). The Service Provider MUST ensure the Request Token cannot be exchanged for an Access Token until the User successfully grants access in Obtaining User Authorization (Obtaining User Authorization).
Service Providerは署名とConsumer Keyを立証します。もし成功したなら、Request TokenとToken Secretを生成し、それらをService Providerのレスポンスパラメータ(Service Provider Response Parameters) (Service Provider Response Parameters)で定義される様にHTTPレスポンスでConsumerに返します。Service ProviderはRequest TokenがUserの認可の取得(Obtaining User Authorization) (Obtaining User Authorization)でUserがアクセス許可に成功するまでAccess Tokenと交換できない事を保証しなければなりません(MUST)。
The response contains the following parameters:
レスポンスは次に続くパラメータを含みます:
- oauth_token:
- The Request Token.
Request Tokenです。
- oauth_token_secret:
- The Token Secret.
Token Secretです。
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Service Parameterによって定義される、何か追加のパラメータです。
If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes). The Service Provider MAY include some further details about why the request was rejected in the HTTP response body as defined in Service Provider Response Parameters (Service Provider Response Parameters).
もしリクエストが立証に失敗するか他の理由で拒否されたなら、Service ProviderはHTTP Response Codes (HTTP Response Codes)で定義される様なふさわしいレスポンスコードを返すべきです(SHOULD)。 Service Providerはリクエストが失敗した理由についてのさらなる詳細をService Providerのレスポンスパラメータ(Service Provider Response Parameters) (Service Provider Response Parameters)で定義される様にHTTPレスポンスボディの中に含めるかもしれません(MAY)。
The Consumer cannot use the Request Token until it has been authorized by the User. Obtaining User authorization includes the following steps:
ConsumerはUserによって認可されるまでRequest Tokenを使う事が出来ません。Userの認可の取得は次に続くステップを含みます:
In order for the Consumer to be able to exchange the Request Token for an Access Token, the Consumer MUST obtain approval from the User by directing the User to the Service Provider. The Consumer constructs an HTTP GET request to the Service Provider’s User Authorization URL with the following parameter:
適切にConsumerがRequest TokenをAccess Tokenと交換する事が出来る様になるために、ConsumerはUserをService Providerに導く事によってUserから承認を取得しなければなりません(MUST)。Consumerは次に続くパラメータを使ったService ProviderのUser Authorization URLへのHTTP GETリクエストを組み立てます:
- oauth_token:
- OPTIONAL. The Request Token obtained in the previous step. The Service Provider MAY declare this parameter as REQUIRED, or accept requests to the User Authorization URL without it, in which case it will prompt the User to enter it manually.
任意です(OPTIONAL)。 前のステップで取得したRequest Tokenです。Service Providerはこのパラメータを必須(REQUIRED)として宣言するかもしれませんし(MAY)、それなしでUser Authorization URLへのリクエストを受け入れるかもしれませんが(MAY)、どちらの場合でもそれを手動で記入する事をUserに促すでしょう。
- oauth_callback:
- OPTIONAL. The Consumer MAY specify a URL the Service Provider will use to redirect the User back to the Consumer when Obtaining User Authorization (Obtaining User Authorization) is complete.
任意です(OPTIONAL)。ConsumerはService ProviderがUserの認可の取得(Obtaining User Authorization) (Obtaining User Authorization)が完了したときにUserをConsumerに戻すリダイレクトのために使うだろうURLを指定するかもしれません(MAY)。
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Service Providerによって定義される、何か追加のパラメータです。
Once the request URL has been constructed the Consumer redirects the User to the URL via the User’s web browser. If the Consumer is incapable of automatic HTTP redirection, the Consumer SHALL notify the User how to manually go to the constructed request URL.
リクエストURLが組み立てられる時、ConsumerはUserのウェブブラウザを使ってUserをそのURLにリダイレクトします。もしConsumerが自動的にHTTPリダイレクトする能力がないなら、ConsumerはUserに組み立てたリクエストURLに手動で行く方法を知らせるものとします(SHALL)。
Note: If a Service Provider knows a Consumer to be running on a mobile device or set-top box, the Service Provider SHOULD ensure that the User Authorization URL and Request Token are suitable for manual entry.
Note: もしService ProviderがConsumerがモバイルでバイスかセットトップボックスの上で動作している事を知っているなら、Service ProviderはUser Authorization URLとReqeust Tokenが手動での記入に適している事を保証すべきです(SHOULD)。
The Service Provider verifies the User’s identity and asks for consent as detailed. OAuth does not specify how the Service Provider authenticates the User. However, it does define a set of REQUIRED steps:
Service ProviderはUserの識別子を立証し、詳細な同意を求めます。OAuthはService ProviderがUserを認証する方法を明記しません。しかしながら、必須(REQUIRED)ステップのセットを定義します:
Service Providerはまず、同意を求める前にUserの識別子を立証しなければなりません(MUST)。Userがまだそうしていないなら、Userに参加を促すかもしれません(MAY)。
Service ProviderはConsumerが要求するアクセスに関するUserの情報を提示します(Consumer Developerによって示されるような)。その情報はアクセスの持続期間と提供されるProtected Resourceを含みます。その情報はService Providerに特有のほかの詳細を含むかもしれません(MAY)。
UserはService Providerに対してUserの代わりにConsumerがProtected Resourceにアクセスするための許可を与える事に承諾か拒否しなければなりません(MUST)。もしUserがConsumerのアクセスを拒否したなら、そのService ProviderはProtected Resourceへのアクセスを許可してはなりません(MUST NOT)。
When displaying any identifying information about the Consumer to the User based on the Consumer Key, the Service Provider MUST inform the User if it is unable to assure the Consumer’s true identity. The method in which the Service Provider informs the User and the quality of the identity assurance is beyond the scope of this specification.
Consumerに関する識別情報をConsumer Keyを基にUserに表示するとき、そのService Providerは、Userの真の識別子を保証する事が出来ないなら、Userに知らせなければなりません。Service ProviderがUserに知らせるその方法と識別子の保証の質はこの仕様書の範囲外です。
After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token. If the User denies access, the Consumer MAY be notified that the Request Token has been revoked.
Service ProviderでのUserの認証とConsumerのアクセスに対する許可を与えた後、そのConsumerはRequest Tokenが認可されていてAccess Tokenと交換する準備ができている事を知らされなければなりません(MUST)。もしUserがアクセスを拒否したなら、そのConsumerはRequest Tokenが無効になっている事を知らされるかもしれません(MAY)。
If the Consumer provided a callback URL in oauth_callback (as described in Consumer Directs the User to the Service Provider (Consumer Directs the User to the Service Provider)), the Service Provider constructs an HTTP GET request URL, and redirects the User’s web browser to that URL with the following parameters:
もしConsumerがoauth_callbackでコールバックURLを提供したなら(ConsumerによるUserのService Providerへの導き(Consumer Directs the User to the Service Provider) (Consumer Directs the User to the Service Provider)で定義される様に)、そのService ProviderはHTTP GETリクエストヲ組み立て、Userのウェブブラウザを次に続くパラメータをつけたそのURLにリダイレクトします:
- oauth_token:
- The Request Token the User authorized or denied.
Userが認可か拒否したRequest Tokenです。
The callback URL MAY include Consumer provided query parameters. The Service Provider MUST retain them unmodified and append the oauth_token parameter to the existing query.
コールバックURLはConsumerが提供したクエリパラメータを含むかもしれません(MAY)。Service Providerはそれらを変更せず保持し既存クエリにoauth_tokenパラメータを追加しなければなりません(MUST)。
If no callback URL was provided, the Service Provider instructs the User to manually inform the Consumer that authorization has completed.
もしコールバックURLが提供されなかったなら、Service Providerは認可が完了している事をConsumerに手動で知らせる様にUserに指示します。
The Consumer exchanges the Request Token for an Access Token capable of accessing the Protected Resources. Obtaining an Access Token includes the following steps:
ConsumerはRequest TokenをProtected Resourceへのアクセスを受け入れるAccess Tokenに交換します。Access Tokenの取得は次に続くステップを含みます:
The Request Token and Token Secret MUST be exchanged for an Access Token and Token Secret.
Request TokenとToken SecretはAccess TokenとToken Secretに交換されなければなりません(MUST)。
To request an Access Token, the Consumer makes an HTTP request to the Service Provider’s Access Token URL. The Service Provider documentation specifies the HTTP method for this request, and HTTP POST is RECOMMENDED. The request MUST be signed per Signing Requests (Signing Requests), and contains the following parameters:
Access Tokenを要求する為に、ConsumerはService ProviderのAccess Token URLに対するHTTPリクエストを作ります。Service Provider文書はこのリクエストのHTTPメソッドを明記し、HTTP POSTが推奨されます(RECOMMENDED)。リクエストはリクエストの署名(Signing Requests) (Signing Requests)に従って署名され次に続くパラメータを含まなければなりません(MUST):
- oauth_consumer_key:
- The Consumer Key.
Consumer Keyです。
- oauth_token:
- The Request Token obtained previously.
前に取得されたRequest Tokenです。
- oauth_signature_method:
- The signature method the Consumer used to sign the request.
Consumerがリクエストに署名する為に使う署名方法です。
- oauth_signature:
- The signature as defined in Signing Requests (Signing Requests).
リクエストの署名(Signing Requests) (Signing Requests)で定義されるような署名です。
- oauth_timestamp:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義されるタイムスタンプです。
- oauth_nonce:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義されるnonceです。
- oauth_version:
- OPTIONAL. If present, value MUST be 1.0 . Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. Service Providers’ response to non-1.0 value is left undefined.
任意です(OPTIONAL)。もし与えられるなら、値は1.0でなければなりません(MUST)。パラメータが与えられないなら、Service Providerはプロトコルバージョンを1.0と仮定しなければなりません(MUST)。値が1.0でないService Providerのレスポンスはまだ未定義です。
No additional Service Provider specific parameters are allowed when requesting an Access Token to ensure all Token related information is present prior to seeking User approval.
Servie Provider特有のパラメータは、情報に関連した全てのTokenを保証する為のAccess Tokenの要求をUserの承認を得ようとするより前に与えるとき、許可されません。
The Service Provider MUST ensure that:
Service Providerは保証しなければなりません(MUST):
リクエストの署名が立証に成功していること。
Request TokenがまだAccess Tokenと交換されていないこと。
Request TokenがConsumer Keyとマッチすること。
If successful, the Service Provider generates an Access Token and Token Secret and returns them in the HTTP response body as defined in Service Provider Response Parameters (Service Provider Response Parameters). The Access Token and Token Secret are stored by the Consumer and used when signing Protected Resources requests. The response contains the following parameters:
もし成功なら、Service ProviderはAccess TokenとToken Secretを生成し、それらをService Providerのレスポンスパラメータ(Service Provider Response Parameters) (Service Provider Response Parameters)で定義される様にHTTPレスポンスボディの中で返します。Access TokenとToken SecretはConsumerによって記憶されProtected Resourceリクエストの署名のときに使われます。レスポンスは次に続くパラメータを含みます:
- oauth_token:
- The Access Token.
Access Tokenです。
- oauth_token_secret:
- The Token Secret.
Token Secretです。
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Service Providerによって定義される、何か追加のパラメータです。
If the request fails verification or is rejected for other reasons, the Service Provider SHOULD respond with the appropriate response code as defined in HTTP Response Codes (HTTP Response Codes). The Service Provider MAY include some further details about why the request was rejected in the HTTP response body as defined in Service Provider Response Parameters (Service Provider Response Parameters).
もしリクエストが立証に失敗するか他の理由で拒否される場合、Service ProviderはHTTPレスポンスコード(HTTP Response Codes) (HTTP Response Codes)で定義される様なふさわしいレスポンスコードを返すべきです(SHOULD)。Service ProviderはService Providerのレスポンスパラメータ(Service Provider Response Parameters) (Service Provider Response Parameters)で定義される様なHTTPレスポンスボディの中にリクエストが拒否された理由に関する更なる詳細を含めるかもしれません(MAY)。
After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User. The request MUST be signed per Signing Requests (Signing Requests), and contains the following parameters:
Access TokenとToken Secretの受け取りに成功した後、ConsumerはUserの代わりにProtected Resourceにアクセスする事が出来ます。リクエストはSigning Requests (Signing Requests)に従って署名されなければならず(MUST)、次に続くパラメータを含みます:
- oauth_consumer_key:
- The Consumer Key.
Consumer Keyです。
- oauth_token:
- The Access Token.
Access Tokenです。
- oauth_signature_method:
- The signature method the Consumer used to sign the request.
Consumerがリクエストに署名する為に使った署名方法です。
- oauth_signature:
- The signature as defined in Signing Requests (Signing Requests).
リクエストの署名(Signing Requests) (Signing Requests)で定義されるような署名です。
- oauth_timestamp:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義されるタイムスタンプです。
- oauth_nonce:
- As defined in Nonce and Timestamp (Nonce and Timestamp).
nonceとタイムスタンプ(Nonce and Timestamp) (Nonce and Timestamp)で定義されるnonceです。
- oauth_version:
- OPTIONAL. If present, value MUST be 1.0. Service Providers MUST assume the protocol version to be 1.0 if this parameter is not present. Service Providers’ response to non-1.0 value is left undefined.
任意です(OPTIONAL)。もし与えられるなら、値は1.0でなければなりません(MUST)。パラメータが与えられないなら、Service Providerはプロトコルバージョンを1.0と仮定しなければなりません(MUST)。値が1.0でないService Providerのレスポンスはまだ未定義です。
- Additional parameters:
- Any additional parameters, as defined by the Service Provider.
Service Providerによって定義される、何か追加のパラメータです。
Unless otherwise specified by the Service Provider, the timestamp is expressed in the number of seconds since January 1, 1970 00:00:00 GMT. The timestamp value MUST be a positive integer and MUST be equal or greater than the timestamp used in previous requests.
Service Providerによって別によって指定されない限り、タイムスタンプは"January 1, 1970 00:00:00 GMT"からの秒数で表現されます。タイムスタンプの値は正の整数でなければならず(MUST)、前回のリクエストで使われたタイムスタンプ以上でなければなりません(MUST)。
The Consumer SHALL then generate a Nonce value that is unique for all requests with that timestamp. A nonce is a random string, uniquely generated for each request. The nonce allows the Service Provider to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel (such as HTTP).
Consumerはタイムスタンプをつけた全てのリクエストに関してユニークであるnonceの値を生成するものとします(SHALL)。nonceはランダムな文字列で、それぞれのリクエストに関してユニークに生成されます。nonceは Service Providerにリクエストが決して前に作られていない事の証明を可能にし、安全でないチャネル(HTTPなど)越しに行われたリクエストのときのリプレイ攻撃を防ぐ助けとなります。
All Token requests and Protected Resources requests MUST be signed by the Consumer and verified by the Service Provider. The purpose of signing requests is to prevent unauthorized parties from using the Consumer Key and Tokens when making Token requests or Protected Resources requests. The signature process encodes the Consumer Secret and Token Secret into a verifiable value which is included with the request.
全てのTokenリクエストとProtected ResourceリクエストはConsumerによって署名されService Providerによって立証されなければなりません(MUST)。リクエストを署名する目的は、TokenリクエストかProtected Resourceリクエストを作るときにConsumer KeyとTokenを使う事から認可されてないパーティを予防する事です。署名プロセスはリクエストに含まれる立証可能な値にConsumer SecretとToken Secretをエンコードします。
OAuth does not mandate a particular signature method, as each implementation can have its own unique requirements. The protocol defines three signature methods: HMAC-SHA1, RSA-SHA1, and PLAINTEXT, but Service Providers are free to implement and document their own methods. Recommending any particular method is beyond the scope of this specification.
OAuthは、それぞれの実装がそれ自身が独特な要件を持つ事が出来る様に、特有の署名方法を強制しません。プロトコルは3つの署名方法を定義します(HMAC-SHA1とRSA-SHA1とPLAINTEXT)が、Service Providerは実装において自由でそられ自身の方法を文書化します。推奨される何か特有の方法はこの仕様書の範囲外です。
The Consumer declares a signature method in the oauth_signature_method parameter, generates a signature, and stores it in the oauth_signature parameter. The Service Provider verifies the signature as specified in each method. When verifying a Consumer signature, the Service Provider SHOULD check the request nonce to ensure it has not been used in a previous Consumer request.
Consumerはoauth_signature_methodパラメータの中で署名方法を宣言し、署名を生成し、oauth_signatureパラメータの中に納めます。Service Providerはそれぞれの方法で指示される様に署名を立証します。Consumerの署名を立証するとき、Service Providerは以前のConsumerリクエストでそのnonceが使われていない事を保証する為にリクエストのnonceを確認すべきです(SHOULD)。
The signature process MUST NOT change the request parameter names or values, with the exception of the oauth_signature parameter.
署名プロセスはoauth_signatureパラメータを除いて、リクエストパラメータの名前か値を変えてはなりません(MUST NOT)。
The Signature Base String is a consistent reproducible concatenation of the request elements into a single string. The string is used as an input in hashing or signing algorithms. The HMAC-SHA1 signature method provides both a standard and an example of using the Signature Base String with a signing algorithm to generate signatures. All the request parameters MUST be encoded as described in Parameter Encoding (Parameter Encoding) prior to constructing the Signature Base String.
署名の基の文字列はリクエスト要素の連結を単純文字列に再現したものです。その文字列はハッシュか署名のアルゴリズムの入力として使われます。HMAC-SHA1署名方法は標準と署名を生成する為の署名アルゴリズムに署名の基の文字列を使う例の両方を提供します。全てのリクエストパラメータは署名の基の文字列を組み立てる前にパラメータエンコーディング(Parameter Encoding) (Parameter Encoding)で定義される様にエンコードされなければなりません(MUST)。
The request parameters are collected, sorted and concatenated into a normalized string:
リクエストパラメータは集められ、記憶され、正規化された文字列に連結されます:
realmパラメータを除外したOAuthのHTTP Authorizationヘッダ(OAuth HTTP Authorization header) (Authorization Header)の中のパラメータ。
HTTP POSTリクエストのボディ(content-typeがapplication/x-www-form-urlencoded)の中のパラメータ。
URLのクエリパートに追加されたHTTP GET パラメータ([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション3で定義される様な)。
The oauth_signature parameter MUST be excluded.
oauth_signatureパラメータは除外されなければなりません(MUST)。
The parameters are normalized into a single string as follows:
パラメータは次に続く様に単純な文字列に正規化されなければなりません:
パラメータは名前によって記憶され、辞書学のバイト値を使って並べれます。もし2つ以上のパラメータが同じ名前を共有する場合、それらはそれらの値によって並べ替えられます。例えば:
a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t
パラメータはそれらのソートされた順序で単純な文字列に連結されます。それぞれのパラメータについて、値が空だとしても、名前は対応する値と‘=’文字(ASCIIコード61)によって区切られます。それぞれの名前と値のペアは‘&’文字(ASCIIコード38)で区切られます。例えば:
a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t
The Signature Base String includes the request absolute URL, tying the signature to a specific endpoint. The URL used in the Signature Base String MUST include the scheme, authority, and path, and MUST exclude the query and fragment as defined by [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3.
署名の基の文字列はリクエストの絶対URL含み、特定のエンドポイントへの署名を結びつけます。署名の基の文字列で使ったURLは、[RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .)のセクション3で定義される様な、スキームとオーソリティとパスを含まねばならず(MUST)、クエリとフラグメントを除外しなければなりません(MUST)。
If the absolute request URL is not available to the Service Provider (it is always available to the Consumer), it can be constructed by combining the scheme being used, the HTTP Host header, and the relative HTTP request URL. If the Host header is not available, the Service Provider SHOULD use the host name communicated to the Consumer in the documentation or other means.
もしリクエストの絶対URLがService Providerで利用できないなら(Consumerでは常に利用可能)、使われたスキームで始めて、HTTP Hostヘッダ、相対HTTPリクエストURLと組み合わせる事で組み立てることが出来ます。もしHostヘッダが利用できないなら、Service Providerは文書か他の意味でConsumerに伝えたホスト名を使うべきです(SHOULD)。
The Service Provider SHOULD document the form of URL used in the Signature Base String to avoid ambiguity due to URL normalization. Unless specified, URL scheme and authority MUST be lowercase and include the port number; http default port 80 and https default port 443 MUST be excluded.
Service ProviderはURL正規化であいまいさを無効にした署名の基の文字列で使ったURLについて文書化すべきです(SHOULD)。指定されない限り、URLスキームとオーソリティは小文字でなければならず(MUST)、ポート番号を含みます; httpのデフォルトポート番号80とhttpsのデフォルトポート番号443は除倍されなければなりません(MUST)。
For example, the request:
リクエストの例:
HTTP://Example.com:80/resource?id=123
Is included in the Signature Base String as:
署名の基の文字列に含まれるものとして:
http://example.com/resource
The following items MUST be concatenated in order into a single string. Each item is encoded (Parameter Encoding) and separated by an ‘&’ character (ASCII code 38), even if empty.
次に続く事項は順序通りに単純な文字列に連結されなければなりません(MUST)。それぞれの事項はエンコードされ(encoded) (Parameter Encoding)、空であっても‘&’文字(ASCIIコード38)で区切られなければなりません。
リクエストを送る為に使ったHTTPリクエストメソッド。値は大文字でなければならず(MUST)、例えば: HEADやPOSTなど。
セクション 9.1.2 (Construct Request URL)のリクエストURL。
セクション 9.1.1 (Normalize Request Parameters)の正規化されたリクエストパラメータ文字列。
See Signature Base String example in Appendix A.5.1 (Generating Signature Base String).
Appendix A.5.1 (Generating Signature Base String)の署名の基の文字列の例を見てください。
The HMAC-SHA1 signature method uses the HMAC-SHA1 signature algorithm as defined in [RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .) where the Signature Base String is the text and the key is the concatenated values (each first encoded per Parameter Encoding (Parameter Encoding)) of the Consumer Secret and Token Secret, separated by an ‘&’ character (ASCII code 38) even if empty.
HMAC-SHA1署名方法は[RFC2104] (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” .)で定義されるようなHMAC-SHA1署名アルゴリズムを使い、署名の基の文字列がtextでkeyがConsumer SecretとToken Secretが値が空であっても‘&’文字(ASCIIコード38)で区切られて連結された値(それぞれまずパラメータエンコーディング(Parameter Encoding) (Parameter Encoding)に従ってエンコードされている)です。
oauth_signature is set to the calculated digest octet string, first base64-encoded per [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .) section 6.8, then URL-encoded per Parameter Encoding (Parameter Encoding).
oauth_signatureは計算したdigestオクテットストリングがセットされ、まず[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)のセクション6.8に従ってBase64エンコードされ、パラメータエンコーディング(Parameter Encoding) (Parameter Encoding)に従ってURLエンコードされます。
The Service Provider verifies the request by generating a new request signature octet string, and comparing it to the signature provided by the Consumer, first URL-decoded per Parameter Encoding (Parameter Encoding), then base64-decoded per [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .) section 6.8. The signature is generated using the request parameters as provided by the Consumer, and the Consumer Secret and Token Secret as stored by the Service Provider.
Service Providerは、新しいリクエスト署名オクテットストリングを生成し、Consumerによって提供された署名をまずパラメータエンコーディング(Parameter Encoding) (Parameter Encoding)に従ってURLデコードして[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)のセクション6.8に従ったBase64デコードをしたものとそれを比較する事によって、リクエストを立証します。
The RSA-SHA1 signature method uses the RSASSA-PKCS1-v1_5 signature algorithm as defined in [RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .) section 8.2 (more simply known as PKCS#1), using SHA-1 as the hash function for EMSA-PKCS1-v1_5. It is assumed that the Consumer has provided its RSA public key in a verified way to the Service Provider, in a manner which is beyond the scope of this specification.
RSA-SHA1署名方法は[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .)のセクション8.2(単純にPKCS#1として知られる)で定義される様なRSASSA-PKCS1-v1_5署名アルゴリズムを使い、EMSA-PKCS1-v1_5のためのハッシュ関数としてSHA-1を使います。ConsumerはService Providerに立証される方法としてそのRSA公開鍵が提供されている事を仮定しますが、方法についてはこの仕様の範囲外です。
The Signature Base String is signed using the Consumer’s RSA private key per [RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .) section 8.2.1, where K is the Consumer’s RSA private key, M the Signature Base String, and S is the result signature octet string:
署名の基の文字列は[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .)のセクション8.2.1に従ってConsumerのRSA秘密鍵を使って署名され、KはConsumerのRSA秘密鍵で、Mは署名の基の文字列で、Sは結果の署名オクッテットストリングです:
S = RSASSA-PKCS1-V1_5-SIGN (K, M)
oauth_signature is set to S, first base64-encoded per [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .) section 6.8, then URL-encoded per Parameter Encoding (Parameter Encoding).
oauth_signatureには、まず[RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .)のセクション6.8に従ってBase64エンコードされ、次にParameter Encoding (パラメータエンコーディング(Parameter Encoding))に従ってURLエンコードされたSがセットされます。
The Service Provider verifies the signature per [RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .) section 8.2.2, where (n, e) is the Consumer’s RSA public key, M is the Signature Base String, and S is the octet string representation of the oauth_signature value:
Service Providerは、(n, e)がConsumerのRSA公開鍵で、Mが署名の基の文字列、Sがoauth_signatureの値で表現されるオクテットストリングとして、[RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .)のセクション8.2.2に従って署名を立証します:
RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
The PLAINTEXT method does not provide any security protection and SHOULD only be used over a secure channel such as HTTPS. It does not use the Signature Base String.
PLAINTEXT方法は何のセキュリティ保護も提供せず、HTTPSのような安全なチャネル越しにのみ使われるべきです(SHOULD)。署名の基の文字列を使いません。
oauth_signature is set to the concatenated encoded values of the Consumer Secret and Token Secret, separated by a ‘&’ character (ASCII code 38), even if either secret is empty. The result MUST be encoded again.
oauth_signatureには、Consumer SecretとToken Secretの値をエンコードして、どちらかが空だとしても、‘&’文字(ASCIIコード38)で区切って連結したものがセットされます。結果はもう一度エンコードされなければなりません(MUST)。
These examples show the value of oauth_signature for Consumer Secret djr9rjt0jd78jf88 and 3 different Token Secrets:
これらの例はConsumer Secretをdjr9rjt0jd78jf88とした3つの異なるToken Secretに関するoauth_signatureの値を示します:
- jjd999tj88uiths3:
- oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3
- jjd99$tj88uiths3:
- oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3
- Empty:
- oauth_signature=djr9rjt0jd78jf88%26
The Service Provider verifies the request by breaking the signature value into the Consumer Secret and Token Secret, and ensures they match the secrets stored locally.
Service Providerは、署名をConsumer SecretとToken Secretに分割し、それらがローカルに記憶したsecretとマッチする事を保証する事によってリクエストを立証します。
This section applies only to the Request Token and Access Token requests. In general, the Service Provider SHOULD use the response codes defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) Section 10. When the Service Provider rejects a Consumer request, it SHOULD respond with HTTP 400 Bad Request or HTTP 401 Unauthorized.
このセクションはRequest TokenとAccess Tokenのリクエストにのみ適用します。一般的に、Service Providerは[RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .)のセクション10で定義されるレスポンスコードを使うべきです(SHOULD)。Service ProviderがConsumerのリクエストを拒絶するとき、"HTTP 400 Bad Request"か"HTTP 401 Unauthorized"を返すべきです(SHOULD)。
サポートしないパラメータ
サポートしない署名方法
必須パラメータがない
OAuth Protocol Parameterの重複
不正なConsumer Key
不正もしくは期限切れのToken
不正な署名
不正もしくは使用済みnonce
In this example, the Service Provider photos.example.net is a photo sharing website, and the Consumer printer.example.com is a photo printing website. Jane, the User, would like printer.example.com to print the private photo vacation.jpg stored at photos.example.net.
この例で、Service Providerの"photos.example.net"は写真共有ウェブサイトで、Consumerの"printer.example.com"は写真印刷ウェブサイトです。UserのJaneは、"photos.example.net"で保管される写真vacation.jpgを"printer.example.com"で印刷しようとしています。
When Jane signs-into photos.example.net using her username and password, she can access the photo by going to the URL http://photos.example.net/photo?file=vacation.jpg. Other Users cannot access that photo, and Jane does not want to share her username and password with printer.example.com.
Janeが"photos.example.net"に彼女のユーザ名とパスワードを使ってサインインするとき、彼女はhttp://photos.example.net/photo?file=vacation.jpgというURLに行く事で写真にアクセスする事が出来ます。他のUserはその写真にアクセスする事が出来ず、Janeは彼女のユーザ名とパスワードを"printer.example.com"との共有を望みません。
The requests in this example use the URL query method when sending parameters. This is done to simplify the example and should not be taken as an endorsement of one method over the others.
この例のリクエストはパラメータを送るときにURLクエリメソッドを使います。これは例を単純にするためで、他のもの以上の方法として支持すると受け取るべきではありません。
The Service Provider documentation explains how to register for a Consumer Key and Consumer Secret, and declares the following URLs:
Service Providerの文書は Consumer KeyとConsumer Secretの登録方法を説明し、次に続くURLを宣言します:
- Request Token URL:
- https://photos.example.net/request_token, using HTTP POST
- User Authorization URL:
- http://photos.example.net/authorize, using HTTP GET
- Access Token URL:
- https://photos.example.net/access_token, using HTTP POST
- Photo (Protected Resource) URL:
- http://photos.example.net/photo with required parameter file and optional parameter size
The Service Provider declares support for the HMAC-SHA1 signature method for all requests, and PLAINTEXT only for secure (HTTPS) requests.
Service Providerは 全てのリクエストについてHMAC-SHA1署名方法をサポートし、PLAINTEXTは安全な(HTTPS)リクエストでのみであると宣言します。
The Consumer printer.example.com already established a Consumer Key and Consumer Secret with photos.example.net and advertizes its printing services for photos stored on photos.example.net. The Consumer registration is:
Consumerの"printer.example.com"はすでにConsumer KeyとConsumer Secretを"photos.example.net"と確立しており、"photos.example.net"で保管される写真に関してその印刷サービスを知らせます。Consumerの登記は:
- Consumer Key:
- dpf43f3p2l4k3l03
- Consumer Secret:
- kd94hf93k423kf44
After Jane informs printer.example.com that she would like to print her vacation photo stored at photos.example.net, the printer website tries to access the photo and receives HTTP 401 Unauthorized indicating it is private. The Service Provider includes the following header with the response:
Janeがかの書が"photos.example.net"で保管される彼女の休暇の写真を印刷する事を望むと"printer.example.com"に知らせた後で、印刷ウェブサイトは写真へのアクセスを試みそれがプライベートであると示す"HTTP 401 Unauthorized"を受け取ります。Service Providerはレスポンスに次に続くヘッダを含みます:
WWW-Authenticate: OAuth realm="http://photos.example.net/"
The Consumer sends the following HTTP POST request to the Service Provider:
Consumerは次に続くHTTP POSTリクエストをService Providerに送ります:
https://photos.example.net/request_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_signature_method=PLAINTEXT&oauth_signature=kd94hf93k423kf44%26&oauth_timestamp=1191242090&oauth_nonce=hsu94j3884jdopsl&oauth_version=1.0
The Service Provider checks the signature and replies with an unauthorized Request Token in the body of the HTTP response:
Service Providerは署名を確認しHTTPレスポンスのボディに認可されてないRequest Tokenをつけて答えます:
oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03
The Consumer redirects Jane’s browser to the Service Provider User Authorization URL to obtain Jane’s approval for accessing her private photos.
ConsumerはJaneのブラウザーを彼女のプライベートな写真へのアクセスに関するJaneの承認を得る為にService ProviderのUser Authorization URLにリダイレクトします。
http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready
The Service Provider asks Jane to sign-in using her username and password and, if successful, asks her if she approves granting printer.example.com access to her private photos. If Jane approves the request, the Service Provider redirects her back to the Consumer’s callback URL:
Service ProviderはJaneに彼女のユーザ名とパスワードを使ったサインインを求め、それが成功したなら、"printer.example.com"の彼女のプライベートな写真へのアクセスを許可する事を彼女が承認するか訪ねます。もしJaneがリクエストを承認するなら、Service Providerは彼女をConsumerのコールバックURLに戻すようリダイレクトします:
http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola
Now that the Consumer knows Jane approved the Request Token, it asks the Service Provider to exchange it for an Access Token:
現在、ConsumerはJaneがRequest Tokenを承認した事を知っており、Service ProviderにAccess Tokenと交換する事を求めます:
https://photos.example.net/access_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=hh5s93j4hdidpola&oauth_signature_method=PLAINTEXT&oauth_signature=kd94hf93k423kf44%26hdhd0244k9j7ao03&oauth_timestamp=1191242092&oauth_nonce=dji430splmx33448&oauth_version=1.0
The Service Provider checks the signature and replies with an Access Token in the body of the HTTP response:
Service Providerは署名を確認しHTTPレスポンスのボディにAccess Tokenをつけて返信します:
oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00
The Consumer is now ready to request the private photo. Since the photo URL is not secure (HTTP), it must use HMAC-SHA1.
Consumerは現在プライベートな写真を要求する準備ができています。写真のURLが安全でない(HTTP)なら、HMAC-SHA1を使わなければなりません。
To generate the signature, it first needs to generate the Signature Base String. The request contains the following parameters (oauth_signature excluded) which are ordered and concatenated into a normalized string:
署名を生成する為に、まず署名の基の文字列の生成が必要です。リクエストは次に続くパラメータ(oauth_signature以外)を含み、それらは並べられ正規化した文字列に連結されます:
- oauth_consumer_key:
- dpf43f3p2l4k3l03
- oauth_token:
- nnch734d00sl2jdk
- oauth_signature_method:
- HMAC-SHA1
- oauth_timestamp:
- 1191242096
- oauth_nonce:
- kllo9940pd9333jh
- oauth_version:
- 1.0
- file:
- vacation.jpg
- size:
- original
The following inputs are used to generate the Signature Base String:
次に続く入力は署名の基の文字列を生成する為に使われます:
The Signature Base String is:
署名の基の文字列は:
GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal
HMAC-SHA1 produces the following digest value as a base64-encoded string (using the Signature Base String as text and kd94hf93k423kf44&pfkkdhi9sl3r4s00 as key):
HMAC-SHA1は Base64エンコードされた文字列として次に続くdigestの値を作り出します(署名の基の文字列をtextとして使いkd94hf93k423kf44&pfkkdhi9sl3r4s00をkeyとする):
tR3+Ty81lMeYAr/Fid0kMTYa/WM=
All together, the Consumer request for the photo is:
全て1つの、写真に関するConsumerのリクエスト:
http://photos.example.net/photos?file=vacation.jpg&size=original
Authorization: OAuth realm="http://photos.example.net/",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_token="nnch734d00sl2jdk",
oauth_signature_method="HMAC-SHA1",
oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D",
oauth_timestamp="1191242096",
oauth_nonce="kllo9940pd9333jh",
oauth_version="1.0"
And if using query parameters:
もしクエリパラメータを使うなら:
http://photos.example.net/photos?file=vacation.jpg&size=original&oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=nnch734d00sl2jdk&oauth_signature_method=HMAC-SHA1&oauth_signature=tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D&oauth_timestamp=1191242096&oauth_nonce=kllo9940pd9333jh&oauth_version=1.0
photos.example.net checks the signature and responds with the requested photo.
"photos.example.net"は署名を確認し要求された写真を返します。
The OAuth specification does not describe any mechanism for protecting Tokens and secrets from eavesdroppers when they are transmitted from the Service Provider to the Consumer in Section 6.1.2 (Service Provider Issues an Unauthorized Request Token) and Section 6.3.2 (Service Provider Grants an Access Token). Service Providers should ensure that these transmissions are protected using transport-layer mechanisms such as TLS or SSL.
OAuth仕様書は、セクション 6.1.2 (Service Provider Issues an Unauthorized Request Token)とセクション 6.3.2 (Service Provider Grants an Access Token)で、それらがService ProviderからConsumerに運ばれるときに、盗聴者からトークンと秘密を保護するための何かのメカニズムを記述しません。Service Providerはこれらの伝達がTLSかSSLのようなトランスポート層のメカニズムを使って保護される事を保証すべきです。
When used with PLAINTEXT signatures, the OAuth protocol makes no attempts to protect User credentials from eavesdroppers or man-in-the-middle attacks. The PLAINTEXT signature algorithm is only intended to be used in conjunction with a transport-layer security mechanism such as TLS or SSL which does provide such protection. If transport-layer protection is unavailable, the PLAINTEXT signature method should not be used.
PLAINTEXT署名と一緒に使うとき、OAuthプロトコルは盗聴者やマンインミドル攻撃からUserのクレデンシャルを保護する為の試みをしません。PLAINTEXT署名アルゴリズムはそのような保護を提供するTLSやSSLのようなトランスポート層のセキュリティメカニズムと連携の中で使われることのみ意図されます。もしトランスポート層の保護が利用できないなら、PLAINTEXT署名方法は使われるべきでありません。
While OAuth 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. Service Providers 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.
OAuthがリクエストの完全性を立証する為のメカニズムを提供する間、リクエストの機密性の保証は提供しません。さらなる予防措置がとられない限り、盗聴者は要求するコンテンツへの完全なアクセス権を持つでしょう。Service Providerはそのようなリクエストの一部として送られそうなデータの種類を注意深く考察すべきで、センシティブなリソースを保護する為にトランスポート層のセキュリティメカニズムを使うべきです。
OAuth makes no attempt to verify the authenticity of the Service Provider. A hostile party could take advantage of this by intercepting the Consumer’s requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services based on OAuth, and should require transport-layer security for any requests where the authenticity of the Service Provider or of request responses is an issue.
OAuthはService Providerの信頼性を立証する事を試みません。悪意の第三者は、Consumerのリクエストを奪いミスリーディングや他の謝ったレスポンスを返すことによって、これを利用する事ができるでしょう。Service ProviderはOAuthベースのサービスを開発するときにそのような攻撃を考察すべきで、Service Providerの信頼性やレスポンスの要求が発行される場面で、いかなるリクエストについてもトランスポート層のセキュリティを要求すべきです。
The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is optional. However, [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .) relies on the Authorization and WWW-Authenticate headers to distinguish authenticated content so that it can be protected. Proxies and caches, in particular, may fail to adequately protect requests not using these headers.
HTTP Authorization scheme (OAuth HTTP Authorization Scheme)は任意です。しかしながら、[RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” .)はAuthorizationヘッダとWWW-Authenticateヘッダについて、保護する事が出来る様に認証コンテンツを見分けるために、信頼します。プロクシとキャッシュは、特に、これらのヘッダを使う事を要求せずに十分な保護に失敗するかもしれません。
For example, private authenticated content may be stored in (and thus retrievable from) publicly-accessible caches. Service Providers not using the HTTP Authorization scheme (OAuth HTTP Authorization Scheme) should take care to use other mechanisms, such as the Cache-Control header, to ensure that authenticated content is protected.
例えば、プライベートな認証コンテンツが誰でもアクセスできる(ゆえに回収可能な)キャッシュに保管されるかもしれません。HTTP Authorization scheme (OAuth HTTP Authorization Scheme)を使わないService Providerは認証コンテンツが保護される事を保証する為に、例えばCache-Controlヘッダのような、他のメカニズムを使う事に気をつけるべきです。
The Consumer Secret and Token Secret function the same way passwords do in traditional authentication systems. In order to compute the signatures used in the non-PLAINTEXT methods, the Service Provider 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.
Consumer SecretとToken Secretは伝統的な認証システムに置けるパスワードと同じ働きをします。PLAINTEXTでない方法を使って署名を計算するために、Service Providerはプレーンテキスト形式でこれらの秘密にアクセスできなければなりません。これは対照的で、例えば、モダンOSは唯一の方法であるユーザのクレデンシャルのハッシュを保管します。
If an attacker were to gain access to these secrets - or worse, to the Service Provider’s database of all such secrets - he or she would be able to perform any action on behalf of any User. Accordingly, it is critical that Service Providers protect these secrets from unauthorized access.
もし攻撃者がこれらの秘密へのアクセスを獲得したなら - もしくはより悪く、Service Providerの全てのそのような秘密のデータベース - 、彼か彼女はいかなるUserの代わりにいかなる行動も可能となります。それゆえに、Service Providerが認可されないアクセスからこれらの秘密を保護する事は重大です。
In many applications, the Consumer application will be under the control of potentially untrusted parties. For example, if the Consumer is a freely available desktop application, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the Consumer Secret used to authenticate the Consumer to the Service Provider.
多くのアプリケーションで、Consumerアプリケーションは潜在的に信頼性の無いパーティのコントロール下にあるでしょう。例えば、もしConsumerがデスクトップアプリケーションを自由に利用できるなら、攻撃者は解析の為にコピーをダウンロードする事が出来るかもしれません。そのようなケースで、攻撃者はConsumerをService Providerで認証する為に使ったConsumer Secretを復元できるかもしれません。
Accordingly, Service Providers should not use the Consumer Secret alone to verify the identity of the Consumer. Where possible, other factors such as IP address should be used as well.
それゆえに、Service ProviderはConsumerの識別子を立証する為にConsumer Secretのみを使うべきではありません。可能なら、IPアドレスの様な他の要因を同様に使うべきです。
Wide deployment of OAuth and similar protocols may cause Users to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If Users 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 Users’ passwords.
OAuthの広範囲な開発と類似したプロトコルはUserをリダイレクトしたウェブサイトでパスワードの記入を求められるならわしに慣れさせる原因となるかもしれません。もしUserがクレデンシャルを記入する前にウェブサイトの信頼性を立証する事に注意深くない場合、この習わしをUserのパスワードを盗む為に利用する事が攻撃者にとって可能になるでしょう。
Service Providers should attempt to educate Users about the risks phishing attacks pose, and should provide mechanisms that make it easy for Users to confirm the authenticity of their sites.
Service Providerはフィッシング攻撃が引き起こすリスクについてUserを教育する事を試みるべきで、サイトの信頼性を確認する事がユーザにとって簡単になる様なメカニズムを提供すべきです。
By itself, OAuth does not provide any method for scoping the access rights granted to a Consumer. A Consumer either has access to Protected Resources or it doesn’t. Many applications will, however, require greater granularity of access rights. For example, Service Providers 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.
自身によって、OAuthはConsumerにアクセスを正しく許可した範囲決定に関する何かの方法を提供しません。ConsumerはProtected Resourceにアクセス可能かそうでないかどちらか一方です。多くのアプリケーションはそれでよいでしょう、しかしながら一方で、アクセス権のより大きな粒度を要求します。例えば、Service ProviderはいくつかのProtected Resourceへのアクセスを許可して他を許可しない事を可能にしたいと望むか、それらProtected Resourceに制限したアクセスだけを(例えば読み込み専用アクセスのような)許可する事を望むかもしれません。
When implementing OAuth, Service Providers should consider the types of access Users may wish to grant Consumers, and should provide mechanisms to do so. Service Providers should also take care to ensure that Users understand the access they are granting, as well as any risks that may be involved.
OAuthを実装するときに、Service ProviderはUserがConsumerに許可する事を望むかもしれないアクセスの種類を考察すべきで、そうするためのメカニズムを提供すべきです。Service Providerは、巻き込まれるかもしれない何かしらのリスクだけでなく、Userの彼らが許可するアクセスへの理解を保証する事にもまた注意を払うべきです。
Unless a transport-layer security protocol is used, eavesdroppers will have full access to OAuth requests and signatures, and will thus be able to mount offline brute-force attacks to recover the Consumer’s credentials used. Service Providers should be careful to assign Token Secrets and Consumer Secrets which are long enough - and random enough - to resist such attacks for at least the length of time that the secrets are valid.
トランスポート層の安全なプロトコルが使われない限り、盗聴者はOAuthリクエストと署名への完全なアクセスが可能でしょうし、それゆえにConsumerの使われたクレデンシャルを復元する為のオフラインのブルートフォース攻撃を仕掛ける事が可能でしょう。Service Providerは、秘密が有効である最低限の時間の長さの間そのような攻撃に対抗する為に、Token SecretとConsumer Secretを十分に長いもの - そして十分にランダムな - を割り当てるように注意すべきです。
For example, if Token Secrets are valid for two weeks, Service Providers should ensure that it is not possible to mount a brute force attack that recovers the Token Secret in less than two weeks. Of course, Service Providers are urged to err on the side of caution, and use the longest secrets reasonable.
例えば、もしToken Secretが2週間有効なら、Service Providerはブルートフォース攻撃を仕掛ける事で2週間以内にToken Secretを復元する事が可能ではないと保証すべきです。もちろん、Service Providerは慎重でありすぎる事が強く迫られ、最長の秘密の利用は理にかなっています。
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 which nevertheless exhibit patterns or other weaknesses which make cryptanalysis or brute force attacks easier. Implementors should be careful to use cryptographically secure PRNGs to avoid these problems.
十分に高品質なこれらの秘密を生成する為に疑似乱数生成器(PRNG)が使われる事は同様に重要です。多くのPRNG実装はランダムに登場するかもしれない番号シーケンス生成しますが、それにもかかわらずパターンを示すか他の暗号分解読の弱点かブルートフォース攻撃の容易さがあります。実装はこれらの問題を回避する為に暗号的に安全なPRNGを使う様に注意すべきです。
The OAuth protocol has a number of features which may make resource exhaustion attacks against Service Providers possible. For example, if a Service Provider includes a nontrivial amount of entropy in Token Secrets as recommended above, then an attacker may be able to exhaust the Service Provider’s entropy pool very quickly by repeatedly obtaining Request Tokens from the Service Provider.
OAuthプロトコルはService Providerに対するリソース消耗攻撃を可能とするかもしれないいくつかの特徴をもちます。例えば、もしService Providerが上部で推奨された様なToken Secretにささいではないエントロピーの総量を含むなら、そのとき攻撃者はService ProviderからRequest Tokenを繰り返し取得する事でService Providerのエントロピープールをとても素早く消耗させ浮ことが出来るかもしれません。
Similarly, OAuth requires Service Providers 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, OAuth can require Service Providers 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 Service Provider.
同様に、OAuthは使ったnonceの追跡をService Providerに要求します。もし攻撃者が多くのnonceを素早く使う事が出来るなら、それらを追跡する事を要求されたリソースは利用可能なキャパシティを使い果たすかもしれません。そして再び、OAuthはService Providerに到着したリクエストを立証するために潜在的に高価な計算を行う事を要求する事が出来ます。攻撃者はService Providerに大量の不正リクエストを送る事によってサービス拒否攻撃を行うためにこれを利用するかもしれません。
Resource Exhaustion attacks are by no means specific to OAuth. However, OAuth implementors should be careful to consider the additional avenues of attack that OAuth 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 OAuth, Service Providers should consider which of these presents a more serious risk for their application and design accordingly.
リソース消耗攻撃はOAuthに固有のことではありません。しかしながら、OAuth実装は更なる攻撃の手段にOAuthをさらす事の考察に注意すべきで、それ相応にそれらの実装を設計すべきです。例えば、エントロピー欠乏は例によって、システムが新しいエントロピーを待つ間の完全なサービス拒否か、他の弱い(簡単に推測できる)秘密のどちらか一方に起因します。OAuthを実装するとき、Service Providerはアプリケーションと設計に相応のこれら現存する多くの深刻なリスクを考察すべきです。
SHA-1, the hash algorithm used in HMAC-SHA1 signatures, has been shown (De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .) [SHA1] to have a number of cryptographic weaknesses that significantly reduce its resistance to collision attacks. Practically speaking, these weaknesses are difficult to exploit, and by themselves do not pose a significant risk to users of OAuth. They may, however, make more efficient attacks possible, and NIST has announced (National Institute of Standards and Technolog, NIST., “NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1,” .) [NIST] that it will phase out use of SHA-1 by 2010. Service Providers should take this into account when considering whether SHA-1 provides an adequate level of security for their applications.
SHA-1、HMAC-SHA1署名で使われるハッシュアルゴリズムは、衝突攻撃の為の抵抗力を下げる重大な暗号的な弱点が幾つかある事を[SHA1]に示し続けています (De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .)。実質的に話すと、これらの弱点は利用の為には難しいく、それら自身によってはOAuthのユーザの重大なリスクを引き起こしません。それはらは、しかしながら、更なる有効な攻撃を可能にするかもしれず、NISTは[NIST]でSHA-1の利用を2010年に段階的撤去すると公示 (National Institute of Standards and Technolog, NIST., “NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1,” .)しています。Service Providerは、SHA-1がアプリケーションにとって十分なセキュリティレベルを提供するかどうか考慮するときに、これを考慮すべき事として扱うべきです。
The Signature Base String has been designed to support the signature methods defined in this specification. When designing additional signature methods, the Signature Base String should be evaluated to ensure compatibility with the algorithms used.
署名の基の文字列はこの仕様書の中で定義される署名方法をサポートする為に設計されています。追加の署名方法を設計するとき、署名の基の文字列は使われたアルゴリズムに付いて互換性を保証するか評価されるべきです。
The Signature Base String cannot guarantee the order in which parameters are sent. If parameter ordering is important and affects the result of a request, the Signature Base String will not protect against request manipulation.
署名の基の文字列はパラメータが送られた順番を保証できません。もしパラメータの並びが重要でリクエストの結果に作用するなら、署名の基の文字列はリクエスト操作に対して保護されないでしょう。
| OAuth Core Workgroup | |
| Email: | spec@oauth.net |