[10] OAuth は、Webアプリケーションの認証に関する仕様群です。
[9] それぞれの版も、細かな違いのある版がいくつかあります。詳しくはそれぞれの項を参照。
[4] OAuth 1.0 も OAuth 2.0 も、 HTTP での利用を想定しています。
[6] OAuth はリダイレクトによって資源所有者 (の利用者エージェント) をクライアントと鯖の間で行き来させるのが大きな特徴になっています。 しかし xAuth や OAuth 2.0 の一部の認可承諾フローのように、 リダイレクトを用いないものもあります。
[7] また通常は HTTPリダイレクトを用いますが、同様の他の仕組みを用いても構わないことになっています (OAuth 2.0 では仕様書に明記されています >>2)。
[14] OAuth 2.0 では、素片識別子を含む URL
にリダイレクトすることがあります (認可エンドポイント参照)。
OAuth 2.0 の仕様書は、 Location:
ヘッダーに素片識別子を指定することに対応していない利用者エージェントがあるため、
開発者は注意するべきである >>13 と述べています。
その上で、対策の一例としてリダイレクトURLにリンクした
「続行」ボタンを含めたHTML文書を返す方法がある >>13 と言っています。
[16] Web 2.0 時代、Webアプリケーション同士が Web API によって連携する形態のマッシュアップが流行し、
認証についても基本認証、ダイジェスト認証、WSSE、
Flickr Authentication API (api_sig)、
Yahoo! BBAuth、Delegated Authentication、
Facebook の signed_request、livedoor Auth、
はてな認証APIなど様々な形が試されていました。
[17] そのような流れの中で、異なる Webアプリケーションであっても共通のプロトコルにより、 末端利用者が他の Webアプリケーションに直接合言葉を預けることなしに Web API を利用させられるようにすることが望まれ、 OAuth 1.0 が開発されることとなりました。
[18] OAuth は元々 API の利用のために他の Webアプリケーションにアクセストークンを発行することが目的のプロトコルでしたが、 他のWebアプリケーションにおけるアカウントを自アプリケーションにおける利用者の識別に流用する、 いわゆるOAuthログインが盛んに用いられるようになりました。アプリケーションを超えたアカウントの統合としては以前から OpenID (1.0) が存在していましたが、使い勝手の悪さから普及していませんでした。 OAuthログインはその潜在的需要を置き換えることになりました。
[19] OAuth 1.0 の利用が広がる中で、署名の実装の難しさや Webアプリケーションではないネイティブアプリケーション等をクライアントとして用いる場合が増えてきたことなどから、 より単純化したり、異なる利用形態をカバーしたりする必要が生じてきました。 そこで OAuth 2.0 が開発され、 OAuth 1.0 にかわって広く用いられるようになってきています。
[20] Twitter など、 OAuth 2.0 に移行せず OAuth 1.0 を提供し続けているWebサービスもあります。 両者に互換性はないため、汎用クライアントはどちらのプロトコルにも対応せざるを得ない状況が続いています。
[1] Gmail APIs and Tools - Google Code ( 版) <http://code.google.com/intl/ja/apis/gmail/oauth/>
[3] OAuth - Wikipedia, the free encyclopedia ( 版) <http://en.wikipedia.org/wiki/OAuth>
OAuth 2 access tokens granted by Quay.io applications can invoke docker pull and docker push on behalf of the user if they have the repo:read and repo:write scopes (respectively).