[10] [DFN[[[OAuth]]]] は、[[Webアプリケーション]]の[[認証]]に関する仕様群です。 * 仕様書 [REFS[ - [2] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [13] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) ]REFS] * OAuth の版 [8] [[OAuth]] にはいくつかの版があります。 [FIG(short list)[ - [[OAuth 1.0]] - [[OAuth 2.0]] - [[OAuth WRAP]] - [[xAuth]] - [[OAuth Echo]] ]FIG] [9] それぞれの版も、細かな違いのある版がいくつかあります。詳しくはそれぞれの項を参照。 [11] 現在では [[OAuth 2.0]] を使うのが好ましいと考えられています。 * HTTP との関係 [4] [[OAuth 1.0]] も [[OAuth 2.0]] も、 [[HTTP]] での利用を想定しています。 ;; [5] 独自に他の[[プロトコル]]にも拡張している実装もあります。 その場合でも[[アクセストークン]]を他の[[プロトコル]]で利用するのに限られるのが普通で、 [[アクセストークン]]の取得には [[HTTP]] を使っているようです。 [6] [[OAuth]] は[[リダイレクト]]によって[[資源所有者]] (の[[利用者エージェント]]) を[[クライアント]]と[[鯖]]の間で行き来させるのが大きな特徴になっています。 しかし [[xAuth]] や [[OAuth 2.0]] の一部の[[認可承諾]]フローのように、 [[リダイレクト]]を用いないものもあります。 [7] また通常は [[HTTPリダイレクト]]を用いますが、同様の他の仕組みを用いても構わないことになっています ([[OAuth 2.0]] では仕様書に明記されています [SRC[>>2]])。 [14] [[OAuth 2.0]] では、[[素片識別子]]を含む [[URL]] に[[リダイレクト]]することがあります ([[認可エンドポイント]]参照)。 [[OAuth 2.0]] の仕様書は、 [CODE(HTTP)@en[[[Location:]]]] [[ヘッダー]]に[[素片識別子]]を指定することに対応していない[[利用者エージェント]]があるため、 開発者は注意する[RUBYB[べき]@en[should]]である [SRC[>>13]] と述べています。 その上で、対策の一例として[[リダイレクトURL]]に[[リンク]]した 「続行」ボタンを含めた[[HTML文書]]を返す方法がある [SRC[>>13]] と言っています。 ;; [15] そのような[[利用者エージェント]]はとても[[Web互換]]とは言えず、 確かに歴史的に存在していたとはいえ、どれだけ現存するか謎です。 本当に開発者がそんなものに注意する必要があるのかは疑問です。 * 歴史 [16] [[Web 2.0]] 時代、[[Webアプリケーション]]同士が [[Web API]] によって連携する形態の[[マッシュアップ]]が流行し、 [[認証]]についても[[基本認証]]、[[ダイジェスト認証]]、[[WSSE]]、 [[Flickr Authentication API]] ([CODE[[[api_sig]]]])、 [[Yahoo!]] [[BBAuth]]、[[Delegated Authentication]]、 [[Facebook]] の [[signed_request]]、[[livedoor 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] [CITE[Gmail APIs and Tools - Google Code]] ([TIME[2010-04-02 10:22:41 +09:00]] 版) [3] [CITE@en[OAuth - Wikipedia, the free encyclopedia]] ([TIME[2011-10-12 14:51:25 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [21] [CITE@en[Quay Documentation]] ([TIME[2017-07-07 06:53:30 +09:00]]) ]FIGCAPTION] > 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). ]FIG]