OAuth認証

OAuth

[10] OAuth は、Webアプリケーション認証に関する仕様群です。

仕様書

OAuth の版

[8] OAuth にはいくつかの版があります。

[9] それぞれの版も、細かな違いのある版がいくつかあります。詳しくはそれぞれの項を参照。

[11] 現在では OAuth 2.0 を使うのが好ましいと考えられています。

HTTP との関係

[4] OAuth 1.0OAuth 2.0 も、 HTTP での利用を想定しています。

[5] 独自に他のプロトコルにも拡張している実装もあります。 その場合でもアクセストークンを他のプロトコルで利用するのに限られるのが普通で、 アクセストークンの取得には HTTP を使っているようです。

[6] OAuthリダイレクトによって資源所有者 (の利用者エージェント) をクライアントの間で行き来させるのが大きな特徴になっています。 しかし xAuthOAuth 2.0 の一部の認可承諾フローのように、 リダイレクトを用いないものもあります。

[7] また通常は HTTPリダイレクトを用いますが、同様の他の仕組みを用いても構わないことになっています (OAuth 2.0 では仕様書に明記されています >>2)。

[14] OAuth 2.0 では、素片識別子を含む URLリダイレクトすることがあります (認可エンドポイント参照)。 OAuth 2.0 の仕様書は、 Location: ヘッダー素片識別子を指定することに対応していない利用者エージェントがあるため、 開発者は注意するべき (should) である >>13 と述べています。 その上で、対策の一例としてリダイレクトURLリンクした 「続行」ボタンを含めたHTML文書を返す方法がある >>13 と言っています。

[15] そのような利用者エージェントはとてもWeb互換とは言えず、 確かに歴史的に存在していたとはいえ、どれだけ現存するか謎です。 本当に開発者がそんなものに注意する必要があるのかは疑問です。

歴史

[16] Web 2.0 時代、Webアプリケーション同士が Web API によって連携する形態のマッシュアップが流行し、 認証についても基本認証ダイジェスト認証WSSEFlickr Authentication API (api_sig)、 Yahoo! BBAuthDelegated AuthenticationFacebooksigned_requestlivedoor Authはてな認証APIなど様々な形が試されていました。

[17] そのような流れの中で、異なる Webアプリケーションであっても共通のプロトコルにより、 末端利用者が他の Webアプリケーションに直接合言葉を預けることなしに Web API を利用させられるようにすることが望まれ、 OAuth 1.0 が開発されることとなりました。

OAuth 1.0 も参照。

[18] OAuth は元々 API の利用のために他の Webアプリケーションアクセストークンを発行することが目的のプロトコルでしたが、 他のWebアプリケーションにおけるアカウントを自アプリケーションにおける利用者の識別に流用する、 いわゆるOAuthログインが盛んに用いられるようになりました。アプリケーションを超えたアカウントの統合としては以前から OpenID (1.0) が存在していましたが、使い勝手の悪さから普及していませんでした。 OAuthログインはその潜在的需要を置き換えることになりました。

[19] OAuth 1.0 の利用が広がる中で、署名の実装の難しさや Webアプリケーションではないネイティブアプリケーション等をクライアントとして用いる場合が増えてきたことなどから、 より単純化したり、異なる利用形態をカバーしたりする必要が生じてきました。 そこで OAuth 2.0 が開発され、 OAuth 1.0 にかわって広く用いられるようになってきています。

OAuth 2.0 も参照。

[20] Twitter など、 OAuth 2.0 に移行せず OAuth 1.0 を提供し続けているWebサービスもあります。 両者に互換性はないため、汎用クライアントはどちらのプロトコルにも対応せざるを得ない状況が続いています。

関連

[12] OpenID とは関わりがありますが、別のものです。

メモ

[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>

[21] Quay Documentation () <https://docs.quay.io/api/>

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).