OAuth Part I: Overview の訳

http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-i-overview/
の訳

機械翻訳(重要でないところ)と見直し部の混在。

--> あいかわらず機械翻訳は、間違いが多い。
and がつながるときは、壊滅である。まあしかし、早く単語の訳がでることはいい。

-----------------------------------------------

Beginner’s Guide to OAuth   Part I: Overview
OAuthへのビギナーガイド

By Eran Hammer-Lahav
Thursday October 4, 2007 2007-10-04

This post contains obsolete or incorrect information. For a more recent update, please visit The Authoritative Guide to OAuth 1.0
With OAuth reaching its final draft (OAuth Core 1.0 Draft 4) last night, it is time for those of you new to the protocol to dive in and learn what it is all about. I have written in a previous post about the history behind OAuth, its use cases, and when it is (or isn’t) applicable. People seems to like my metaphor of a valet key, which John Panzer rephrased “OAuth: Your valet key for the Web”.

この投稿は時代遅れの、または、不正確な情報を含んでいます。 より最近のアップデートには、OAuth1.0へのAuthoritativeガイドを訪問してください。
OAuthが昨夜最終的な草稿(OAuth Core1.0Draft4)に達しています。
だからもう時間です。あなたが新しくプロトコルへ飛び込んで、それが何に関するすべてであるかを学べます。
私はOAuthの背景の歴史を、前の投稿に書きました。その使用の例、それがどこで適切でありまたどこでそうではないかも書きました。

人びとは、ジョン Panzerはキーを言い直してくれた「OAuth:ウェブにあなたの、召使キー。」という、私の召使キーの比喩が好きであるように思えます。

Beginner’s Guide to OAuth   Part I

Introduction

This guide is intended for a technical audience with focus on implementation. I dedicate one section to the end-user perspective which is something I expect many others will address with mockups, user interface designs, best practices guides, and of course working services. To make the most out of this guide, keep the specification handy as I will be referencing it, walking you through the spec and adding color where needed. This guide does not replace the specification nor can it be used alone for implementation as it is incomplete.

(excite機械翻訳)
このガイドは実現での焦点との技術聴衆のために意図します。 私は多くの他のものが実物大の模型、ユーザーインターフェース設計、最も良い習慣で演説する私がガイド、およびもちろん働くサービスを予想する何かであるエンドユーザ見解に1つのセクションを捧げます。 私がそれに参照をつけるとき、このガイドから大部分作るために、仕様を手元に置いてください、必要であるところで仕様を通してあなたを歩いて、色を加えて。 このガイドは仕様を置き換えません、そして、不完全であるので、実現に単独でそれは使用できません。
End-User Benefits

OAuth allows you to share your private resources (photos, videos, contact list, bank accounts) stored on one site with another site without having to hand out your username and password. There are many reasons why one should not share their private credentials. Giving your email account password to a social network  site so they can look up your friends is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when it’s time to pay. Any restaurant asking for your PIN code will go out of business, but when it comes to the web, users put themselves at risk sharing the same private information. OAuth to the rescue.

(excite機械翻訳)

OAuthはあなたに1つのサイトに別のサイトであなたのユーザ名とパスワードを与える必要はなく格納された私用資源(写真(ビデオ)はリストに連絡します、銀行口座)を共有させます。 それらの個人的な信任状を共有するべきでない多くの理由があります。 彼らがあなたの友人を訪ねることができるようにあなたのメールアカウントパスワードをソーシャルネットワークサイトに与えるのは、もう支払うべき時間であるとき、夕食に行って、あなたの銀行のキャッシュカードと暗証番号コードを給仕に与えるのと同じことです。 あなたのPINコードを求めるどんなレストランも、店じまいするでしょうが、ウェブのこととなると、ユーザは、危険な状態に同じ個人情報を共有しながら、自分たちを置きます。 救出へのOAuth。

Both the valet key and ATM cards are good metaphors for OAuth from a user perspective. Instead of giving your ATM card and PIN code, the card can double as a credit card with a signature authorization. Just like your username and password provide full access to your resources, your ATM card and PIN code provide you with great control over your bank accounts much more than just charging goods. But when you replace the PIN code with your signature, the card becomes very limited and can only be used for limited access.

(excite機械翻訳)
召使キーと銀行のキャッシュカードの両方が利用者の展望からのOAuthに、良い比喩です。 あなたの銀行のキャッシュカードと暗証番号コードを与えることの代わりに、署名承認でカードをクレジットカードの役目も兼ねることができます。あなたのユーザ名とパスワードがまさしくあなたのリソースへの完全なアクセスを提供するように、あなたの銀行のキャッシュカードとPINコードはあなたの銀行口座のかなりのコントロールをあなたにただ商品を請求するよりはるかに提供します。 しかし、あなたが暗証番号コードを署名に取り替えると、カードは、非常に制限されるようになって、限られたアクセサリーに使用できるだけです。

Users don’t care about protocols and standards they care about better experience with enhanced privacy and security. This is exactly what OAuth sets to achieve. With web services on the rise, people expect their services to work together in order to accomplish something new. Instead of using a single site for all their online needs, users use one site for their photos, another for videos, another for email, and so on. No one site can do everything better. In order to enable this kind of integration, sites need to access the user resources from other sites, and these are often protected (private family photos, work documents, bank records). They need a key to get in.

(excite機械翻訳)
ユーザはプロトコルを心配しません、そして、彼らがほとんどより良い経験について気にかける規格はプライバシーとセキュリティを高めました。 これは、まさにOAuthが達成するためにセットすることです。 ウェブサービスが上昇中で、人々は、何か新しいものを達成するために彼らのサービスが一緒に働くと予想します。 彼らのすべてのオンラインニーズにただ一つのサイトを使用することの代わりに、ユーザは彼らのフォト、ビデオのための別のもの、メールのための別のものなどに1つのサイトを使用します。 いいえ1、サイトはすべてを良くすることができます。 この種類の統合を可能にするために、サイトは、他のサイトからユーザリソースにアクセスする必要があります、そして、これらはしばしば保護されます(個人的な家族写真(作業文書)は記録を盛り土します)。 彼らは、入るためにキーを必要とします。

The key used by users is usually a combination of username and password. This can be an OpenID or any other login credential. But this key is too powerful and unrestricted to share around. It also cannot be unshared once handed out except for changing it which will void access to every site, not just the one the user intends to block. OAuth addresses that by allowing users to hand out tokens instead. Each token grants access to a specific site (a video editing site) for specific resources (just videos from last weekend) and for a defined duration (the next 2 hours).

(excite機械翻訳)
通常、ユーザによって使用されたキーは、ユーザ名とパスワードの組み合わせです。 これは、OpenIDかいかなる他のログイン信任状であるかもしれません。 しかし、このキーは、共有できないくらい強力であって、無制限です。 また、それを変える以外に、いったん与えると、それも分配されていないはずがありません(ユーザが妨げるつもりであるものだけではなく、あらゆるサイトへのアクセスを欠如させるでしょう)。 ユーザが代わりに象徴を与えるのを許容することによって、OAuthはそれを記述します。 各象徴は特定のリソース(先週末からのまさしくビデオ)と(次の2時間)定義された持続時間の間、特殊部位(ビデオ編集部位)へのアクセスを承諾します。

Unlike OpenID where users must do something first get an OpenID identity they can use to sign-into sites. OAuth is completely transparent to the users. In many cases (if done right), the end-user will not know anything about OAuth, what it is or how it works. The user experience will be specific to the implementation of both the site requesting access and the one storing the resources, and adjusted to the device being used (web browser, mobile phone, PDA, set-top box).

ユーザが最初に何かをしなければならないOpenIDと異なって、サイトにサインインするために彼らが使用できるOpenIDのアイデンティティを得てください、。
ユーザにとって、OAuthは完全に透明です。
多くの場合(正しくするなら)、エンドユーザは、OAuthについて、それが何であるかまたはどう働くかに関して、何も知らないでしょう。
ユーザー・エクスペリエンスは、サイト要求アクセスとリソースを格納アクセスの両方の実現に特定になるでしょう。そして、使用される装置(ウェブブラウザ、携帯電話、PDA、セットトップボックス)に対して調整されるしょう。

A typical example offered by the spec (Appendix A) is when a user wants to print a photo stored on another site. The interaction goes something like this: the user signs into the printer website and place an order for prints. The printer website asks which photos to print and the user chooses the name of the site where her photos are stored (from the list of sites supported by the printer). The printer website sends the user to the photo site to grant access. At the photo site the user signs into her account and is asked if she really wants to share her photos with the printer. If she agrees, she is sent back to the printer site which can now access the photos. At no point did the user share her username and password with the printer site.

仕様(付録A)によって提供された典型的な例は、ユーザが別のサイトに保存されたフォトを印刷したがっている時です。 相互作用はこのように進んでいます:
ユーザはプリンタウェブサイトにサインインして印刷の注文を置きます。
プリンタウェブサイトは、どのフォトを印刷したらよいかを尋ねます、
そして、ユーザはサイトの名前を選びます。そこでは、彼女のフォトが保存されています
(プリンタによってサポートされたサイトのリストから) 。
プリンタウェブサイトで、アクセス権を与えるためにユーザをフォトサイトに送ります。
フォトサイトでは、ユーザは、彼女のアカウントにサインインして、彼女が本当にプリンタとフォトを共有したがっているかどうか尋ねられます。 彼女が同意するなら、彼女は現在フォトにアクセスできるプリンタサイトに送り返されます。
どんなポイントでも、ユーザは彼女のユーザ名とパスワードをプリンタサイトと共有しません。

Scope

What is publicly known as ‘OAuth’ is really the ‘OAuth Core 1.0’ specification. The Core designation is used to stress that this is the skeleton other extensions and protocols can build upon. OAuth Core 1.0 does NOT by itself provide many desired features such as automated discovery of endpoints, language support, support for XML-RPC and SOAP, standard definition of resource access, OpenID integration, a full range of signing algorithms, and many other great ideas posted to the OAuth group.

(excite機械翻訳)
‘OAuth'として公的に知られていることは、本当に‘OAuth Core1.0'仕様です。 Core名称は、これが他の拡大とプロトコルが当てにすることができる骸骨であると強調するのに使用されます。 OAuth Core1.0自身は終点の自動化された発見や、言語サポートや、XML-RPCのサポートやSOAPなどの希望の多くの特徴を提供しません、リソースアクセスの標準定義、とOpenID統合、最大限の範囲の署名アルゴリズム、および他の多くのすばらしい考えがOAuthグループに投稿しました。

This was intentional and is viewed by the authors as a benefit. As the name implies, Core deals with the most fundamental aspects of the protocol:

(excite機械翻訳)
これは、意図的であり、利益として作者によって見なされます。 名前が含意するように、Coreはプロトコルの最も基本的な局面に対処します:

Establish a mechanism for exchanging a username and password for a token with defined rights (Section 6).
Provide tools to protect these tokens (Section 9).

(excite機械翻訳)
定義された権利(セクション6)でトークンのためのユーザ名とパスワードを交換するためにメカニズムを確立してください。
ツールを提供して、これらのトークン(セクション9)を保護してください。

It is important to understand that security and privacy are not guaranteed by the protocol. In fact, OAuth by itself provides no privacy at all and depends on other protocols to accomplish that (such as SSL). With that said, OAuth can be implemented in a very secure manner and the specification includes a good amount of security considerations to take into account when working with sensitive resources. Just like using passwords together with usernames to gain access, sites will use tokens together with secrets to access resources. And just like passwords, secrets must be protected.

(excite機械翻訳)
セキュリティとプライバシーがプロトコルによって保証されないのを理解するのは、重要です。 事実上、それ自体でOAuthは、それ(SSLなどの)を達成するためにプライバシーを全く提供しないで、他のプロトコルによります。 それが言われている状態で、非常に安全な方法でOAuthを実装することができます、そして、仕様は機密のリソースで働いているとき考慮に入れる相当量のセキュリティ問題を含んでいます。 まさしく、アクセスを得るのにユーザ名と共にパスワードを使用するように、サイトはリソースにアクセスするのに秘密と共にトークンを使用するでしょう。 そして、まさしくパスワードのように、秘密を保護しなければなりません。

Specification Structure
仕様構造

OAuth Core 1.0 includes 13 sections which are ordered in a way that allows a single pass through the spec without the need to go back and forth many times. If you want to dive right in, start with Appendix A, then read sections 3, 4.1, 6, 7, and 5.4. Read sections 5 and 9 when you are ready to implement.

(excite機械翻訳)
何回も前後に行かずに、OAuth Core1.0は仕様に単一パスの通ることを許す方法で注文される13のセクションを含んでいます。 右に飛び込みたいなら、Appendix Aから始まってください、そして、次に、セクション3、4.1、6、7、および5.4を読んでください。 道具に準備ができていたらセクション5と9を読んでください。

Section 1.   List of authors.
Section 2.   General notations used by the spec.
Section 3.   Definitions of important terms used throughout the spec. While most are simple to understand, it is important to read this section a couple of times as it sets the framework for the rest of the document.
Section 4.   Protocol preparations. Before using OAuth, sites must follow a few steps to prepare for the protocol. The spec does not specify how this is done but does provide guidelines as to what information should be documented and established before the first OAuth request is made.
Section 5.   Implementation details on formatting parameters and interaction with the HTTP protocol.
Section 6.   Defines the mechanism for exchanging user credentials with a token. It is the heart of the specification and describes the entire flow including user interaction.
Section 7.   Defines how tokens are actually used to access resources. This short section is where most of OAuth takes place.
Section 8.   technical details about creating nonce and timestamp values. Note that OAuth definition of timestamps does not necessarily means real time is used.
Section 9.   While section 6 covers the first goal of the protocol, to exchange user credentials for a token, this section defines tools to protect the token from abuse. The signature process provides a working prototype and support for future extensions.
Section 10.   Suggested HTTP response codes. OAuth Core leaves much open for individual implementations.
Appendix A.   A complete example for sections 4 to 9. This is a good place to start reading if you intend to implement OAuth. It lets you dig right into the actual requests and see how they work.
Appendix B.   Is an incomplete (as is true for most security papers) list of security considerations. It is absolutely critical that any OAuth implementer reads this thoroughly to understand the risks involved. Deciding on how to address this list is up to each implementation and depends on needs.
Section 11.   List of references and links to external documents.

(excite機械翻訳)
セクション1。 作者のリスト。
セクション2。 仕様によって使用される一般表記。
セクション3。 仕様中で使用される重要な用語の定義。 大部分は理解しているのが簡単ですが、ドキュメントの残りのためにフレームワークの用意をするとき、一度か二度このセクションを読むのは、重要です。
セクション4。 準備について議定書の中で述べてください。 OAuthを使用する前に、サイトは、プロトコルの用意をするために数ステップに従わなければなりません。 OAuthが要求する1番目が作られている前に、仕様は、これがどのように完了しているかを指定しませんが、どんな情報が記録されて、確立されるべきであるかに関してガイドラインを提供します。
セクション5。 形式パラメタに関する実現の詳細とHTTPとの相互作用は議定書を作ります。
セクション6。 ユーザ資格証明書をトークンと交換するためにメカニズムを定義します。 それは、仕様の心であり、ユーザ相互作用を含む全体の流れについて説明します。
セクション7。 トークンがリソースにアクセスするのに実際にどう使用されるかを定義します。 この短い部分は、OAuthの大部分が行われるところです。
一回だけを作成することに関するセクション8技術的詳細とタイムスタンプ値。 タイムスタンプの定義がするOAuthが、必ずリアルタイムが使用されていることを意味するというわけではないことに注意してください。
セクション9。 セクション6は、ユーザ資格証明書をトークンと交換するためにプロトコルの初ゴールをカバーしますが、このセクションは、乱用からトークンを保護するためにツールを定義します。 署名プロセスは将来の拡張の実用試作機とサポートを提供します。
セクション10。 HTTP応答コードを示しました。 OAuth Coreは多くの戸外を個々の実現に出ます。
セクション4?9のための付録のA.のA完全な例。 これは、あなたがOAuthを実装するつもりであるなら読み始める良い場所です。 それで、あなたは、丹念に実際の要求をまさしく調べて、それらがどう働いているかを見ることができます。
付録B.Is、セキュリティ問題の不完全な(ほとんどのセキュリティ書類には、そのままで本当の)リスト。 どんなOAuth implementerもかかわった危険を理解するためにこれを徹底的に読むのは、絶対に重要です。 このリストを扱う方法を決めるのは、各実現まであって、必要性によります。
セクション11。 参考文献一覧と外部のドキュメントへのリンク。

Definitions
定義

Section 3 contains definitions to fundamental protocol concepts referenced throughout the spec. Because understanding OAuth depends on these terms, they deserve some explanation:

(excite機械翻訳)
セクション3は仕様中で参照をつけられる基本的なプロトコル概念に定義を含みます。 OAuthを理解するのがこれらの諸条件でよるので、何らかの説明に値します:


Service Provider.   The Service Provider controls all aspects of the OAuth implementation. The Service Provider is the term used to describe the website or web-service where the restricted resources are located. It can be a photo sharing site where users keep albums, an online bank service, a microblogging site, or any other service where ‘user’s private stuff’ is kept. OAuth does not mandate that the Service Provider will also be the identity provider which means the Service Provider can use its own usernames and passwords to authenticate users, or use other systems such as OpenID.

(excite機械翻訳)
Service ProviderはOAuth実現の全面を制御します。 Service Providerは、制限されたリソースが位置している、ウェブサイトかWebサービスについて説明するのに使用される用語です。 ユーザがどこにアルバム、ネット銀行サービス、microbloggingサイト、またはサービスを、いかなる他のも保管するかは、‘ユーザの個人的なもの'が保たれるところの写真共有サイトであるかもしれません。 OAuthは、また、Service ProviderがアイデンティティプロバイダーになるのをService Providerがユーザを認証するのにそれ自身のユーザ名とパスワードを使用するか、またはOpenIDなどの他のシステムを使用できることを意味する強制しません。

User.   The user is why OAuth exists and without users, there is no need for OAuth. The users have ‘stuff’ they don’t want to make public on the Service Provider, but they do want to share it with another site. In OAuth, the protocol stops without manual interaction with the user at least once to receive permission to grant access.

(excite機械翻訳)
ユーザはOAuthが存在する理由です、そして、ユーザがいなければ、OAuthの必要は全くありません。 ユーザには、彼らがService Providerで公表したがっていない‘もの'がありますが、彼らは別のサイトとそれを共有したがっています。 OAuthでは、プロトコルは、アクセサリーを与える許可を受けるためにユーザとの手動の相互作用なしで少なくとも一度止まります。

Consumer.   This is a fancy name for an application trying to access the User’s resources. This can be a website, a desktop program, a mobile device, a set-top box, or anything else connected to the web. The Consumer is the one getting permission to access resources and the Consumer is where the useful part of OAuth happens. OAuth defines ‘Consumer Developer’ as the entity writing code to interact with the Service Provider. ‘Consumer Key’ and ‘Consumer Secret’ will be explained later.

(excite機械翻訳)
これはUserのリソースにアクセスしようとするアプリケーションのための高級名前です。 これは、ウェブに接続されたウェブサイト、デスクトッププログラム、モバイル機器、セットトップボックス、または他の何かであるかもしれません。 Consumerはリソースにアクセスする許可を得るものです、そして、Consumerは、OAuthの役に立つ部分が起こるところです。 OAuthはService Providerと対話するためにコードを書く実体と‘消費者Developer'を定義します。 ‘消費者Key'と‘消費者Secret'は後で説明されるでしょう。

Protected Resources. The ‘stuff’ OAuth protects and allow access to. This can be data (photos, documents, contacts), activities (posting blog item, transferring funds) or any URL with a need for access restrictions.
Tokens   are used instead of User credentials to access resources. A Token is generally a random string of letters and numbers (but not limited to) that is unique, hard to guess, and paired with a Secret to protect the Token from being abused. OAuth defines two different types of Tokens: Request and Access. This are explained later in greater details.

(excite機械翻訳)
‘もの'OAuthは、保護して、アクセスがそうするのを許容します。 これは、データ(フォト、ドキュメント、接触)、活動(基金を振り込んで、ブログ項目を掲示する)またはアクセス制限の必要性があるどんなURLであってもよいです。
トークンは、User資格証明書の代わりにリソースにアクセスするのに使用されます。 一般に、Tokenは、ユニークであって、推測しにくくて、乱用されるのからTokenを保護するためにSecretと対にされる手紙と数(他)の無作為のストリングです。 OAuthはTokensの2つの異なったタイプを定義します: 要求とアクセサリー これは後でよりすばらしい詳細に説明されます。

Continue to Beginner’s Guide to OAuth   Part II : Protocol Workflow ≫