[4] [DFN[[[OAuth 1.0]]]] は、 [[Web API]] へのアクセス権限に関する[[プロトコル]]です。
[5] 非互換で名前以外まったく違った[[プロトコル]]である [[OAuth 2.0]]
によって形式的には[[廃止]]され、新しい実装はそちらを採用することが一般的になっていますが、
依然として [[OAuth 1.0]] を使っている実装も少なくありません。
* 仕様書
[6] [[OAuth 1.0]] は3回正式な仕様書として出版されています。技術的にはほぼ同じ内容ですが、
若干の違いはあります。
[REFS[
= [7] [CITE@en[OAuth Core 1.0]] ([TIME[2014-05-15 01:06:10 +09:00]] 版) (2007年10月)
= [8] [CITE@en[OAuth Core 1.0a]] ([TIME[2014-05-15 01:06:10 +09:00]] 版) (2009年6月)
= [9] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版) (2010年4月)
]REFS]
[10] 最初の2つは OAuth Core Workgroup により出版されましたが、その後 [[IETF]]
に移管 [SRC[>>9]] され[[情報提供RFC]]として発行されました。
現在最初の2つには [[RFC 5849]] を参照するよう注意書きが追加されています。
[11] 最初の版には[[セッション固定攻撃]]に対する脆弱性があったため、 1.0a
で修正されています。
[38]
「Core 1.0」→「Core 1.0a」→「1.0」とわけのわからないバージョンアップが行われたため、
どの版を指しているかに若干の混乱も見られました。
[REFS[
- [20] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版)
- [28] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版)
- [17] [CITE[RFC Errata Report]] ([TIME[2015-02-02 15:51:36 +09:00]] 版)
]REFS]
* 用語
[14] [[RFC 5849]] とそれ以前で用語一式が違っています。
一般には歴史がある旧来の用語が使われているケースが多いようです。
;; [15] [[標準化団体]]が変わると用語が変わるのはよくあることです。
普及している用語を変えられると結局新旧両方覚えないといけなくなるので面倒な話です。。。
* プロトコル
[21] [[OAuth 1.0]] は、
- [[HTTPリダイレクト]]を使った[[認可]]
- それによって得られた[[トークン]]を使った[[認証]]
... で構成されています。
[29] その他次の概念があります。
[FIG(short list)[ [44] [[OAuth 1.0]] の構成要素
- [[消費者]]
- [[サービス提供者]]
- [[資源所有者]]
- [[credentials]]
- [[検証符号]]
- [[引数 (OAuth)]]
- [[scope (OAuth)]]
]FIG]
[41] 他に次の拡張仕様があります。拡張仕様は必ずしも実装されていません (それぞれの項を参照)。
[FIG(middle list)[ [43] [[OAuth 1.0]] の拡張
- [[OAuth Problem Reporting Extension]]
- [CODE(HTTP)@en[[[oauth_body_hash]]]]
- [[OAuth Session Extension]]
- [CODE(HTTP)@en[[[xoauth_response_format]]]]
- [[OAuth Discovery 1.0]]
- [[ScalableOAuth]]
- [CODE(HTTP)@en[[[oauth_token_attributes]]]]
- [[2-legged OAuth]]
- [[xAuth]]
]FIG]
* リダイレクトによる認可
[22] [[リダイレクト]]を使った[RUBYB[認可]@en[authorization]]は、
次の3段階で行います [SRC[>>20]]。
[FIG(steps)[
= [23] [[temporary credentials要求]]: [[クライアント]]が、[[鯖]]から [[temporary credentials]]
([[識別子]]と[[共有秘密]]) を得ます。
= [24] [[資源所有者認可]]: [[資源所有者]]が、[[鯖]]に対して、 ([[temporary credentials]]
によって識別される) [[クライアント]]のアクセス要求に応えることを認可します。
([[資源所有者]]はこの[[エンドポイント]]に[[リダイレクト]]されてきます。)
= [25] [[トークン要求]]: [[クライアント]]が、 [[temporary credentials]]
を使って[[鯖]]から [[token credentials]] を得ます。
]FIG]
;; [27] 第2段階は[[資源所有者]]が [[Webブラウザー]]等でアクセスすることが期待されています。
第1段階と第3段階は[[クライアント]]から[[鯖]]に直接アクセスすることが期待されています。
[26] この3段階の[[エンドポイント]]の [[URL]] を[[鯖]]は[[クライアント]]に[[広告]]する必要があります [SRC[>>20]]。
しかしその方法は規定されていません [SRC[>>20]]。
その [[URL]] は [[query]] を含んでいても構いませんが、
[CODE[[[oauth_]]]] から始まる[[引数]]を含んでは[['''なりません''']] [SRC[>>20]]。
;; [33] 一般的には当該 [[Web API]] の[[ドキュメント]]の類で[[自然言語]]により[[エンドポイント]]と適用できる[[引数]]などを説明することが多いようです。
[FIG(sequence)[
:O:[[資源所有者]]
:C:[[クライアント]]
:S:[[鯖]]
:O -> C:[[OAuth]] 処理開始
:C -> S:※[[一時credentials要求]] ([CODE(HTTP)@en[[[POST]]]])
:S -> C:※[[一時credentials要求]]への[[応答]] ([CODE(HTTP)[[[200]]]] [[一時credentials]]発行)
:C -> O:※[[資源所有者認可]]への[[HTTPリダイレクト]]
:O -> S:[[資源所有者認可]]の[[要求]] ([CODE(HTTP)@en[[[GET]]]])
:S -> O:[[資源所有者認可]]の確認
:O -> S:[[資源所有者認可]]の承認の通知
:S -> O:※[[コールバック]] [[URL]] への[[HTTPリダイレクト]] ([[検証符号]]発行)
:O -> C:[[コールバック]] [[URL]] への[[要求]]
:C -> S:※[[トークン要求]] ([CODE(HTTP)@en[[[POST]]]])
:S -> C:※[[トークン要求]]への[[応答]] ([CODE(HTTP)[[[200]]]] [[トークンcredentials]]発行)
:C -> O:[[OAuth]] 処理完了
]FIG]
;; [18] [[OAuth]] としては「※」の部分を規定しています。それ以外の部分は[[相互運用性]]に直接影響しないので、
具体的にどう動作させるかは実装依存になっています。
[30] [[Google]] や [[Twitter]] はこの方式を [[3-legged OAuth]] [SRC[>>31, >>39]] と呼んでいました。
[32] この方式は [[OAuth 2.0]] の[[承諾型]]のうち[[認可符号]]に相当します。
ただし両者のフローは大きく異なっていて、互換性は全くありません。
[REFS[
- [31] [CITE@ja[OAuth 1.0 for Web Applications - Google Accounts Authentication and Authorization — Google Developers]] ([TIME[2014-12-12 09:19:57 +09:00]] 版)
- [39] [CITE[3-legged authorization | Twitter Developers]] ([TIME[2015-03-05 11:08:34 +09:00]] 版)
]REFS]
* 認証された要求
[34] [[HTTP認証]]では、[[クライアント]]が[[要求]]に [[credentials]]
を含めて送信し、[[鯖]]がそれを受け入れるか判断します。 [[OAuth 1.0]]
でも [[HTTP要求]]に [[credentials]] を含めます。 [[OAuth 1.0]]
では、 [[クライアント]]を表す[[クライアントcredentials]]と、
[[資源所有者]]を表す[[トークンcredentials]]を(両方共)使います。
[35] 詳しくは次の各項を参照。
[FIG(short list)[
- [[認証された要求]]
]FIG]
[36] [CODE(ABNF)@en[[[auth-scheme]]]] [DFN[[CODE(HTTP)@en[[[OAuth]]]]]]
は、 [[OAuth 1.0]] の [[credentials]] や [[challenge]] を表します。
用法については、[[引数 (OAuth 1.0)]] と [[challenge]] を参照してください。
[37] この値は [[RFC 5849]] で規定されました。 [[RFC 723x]] で新設された
[[IANA登録簿]]には [[RFC 7236]] で登録されています [SRC[>>2]]。
[40] [[OAuth 2.0]] において [CODE(ABNF)@en[[[auth-scheme]]]] [CODE(HTTP)@en[[[Bearer]]]]
とするべきところ、 [CODE(HTTP)@en[[[OAuth]]]] を使う実装もあります。
;; [CODE(HTTP)@en[[[Bearer]]]] 参照。
[REFS[
- [2] [CITE@en[RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations]] ([TIME[2014-09-10 00:40:16 +09:00]] 版)
]REFS]
* [CODE@en[XOAUTH]]
[1] [CITE@ja[Gmail Platform — Google Developers]]
( ([TIME[2014-06-25 18:04:07 +09:00]] 版))
> This document defines the SASL mechanism XOAUTH for use with the IMAP AUTHENTICATE and SMTP AUTH commands. It allows the use of OAuth 1.0 authentication parameters to authenticate to a user's Gmail account. The mechanism supports standard "three-legged" OAuth and non-standard "two-legged" OAuth.
[3] [CITE@en[draft-ietf-kitten-sasl-oauth-16 - A set of SASL Mechanisms for OAuth]]
( ([TIME[2014-10-16 12:17:28 +09:00]] 版))
* 関連
[12] 元々 [[OAuth]] は [[OpenID]] とは異なるものでしたが、 [[OAuth]]
を使って[[ログイン]]機能を実装するのが流行し、結果的にそれまでの (あまり普及していなかった)
[[OpenID]] による[[ログイン]]機能を置き換えるものとなりました。
[13] [[xAuth]] は [[OAuth 1.0]] から派生した[[プロトコル]]です。
* メモ
[16] [CITE@ja[特定のクライアントを許可している Twitter ユーザーの Token Credentials を入手する攻撃 - ひだまりソケットは壊れない]]
( ([TIME[2013-03-01 09:31:09 +09:00]] 版))
[19] [CITE[oauth - API needz authorized? - Google Project Hosting]]
([TIME[2015-03-13 11:35:28 +09:00]] 版)
[42] [CITE@en[RFC 7628 - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth]]
([TIME[2015-09-01 15:39:29 +09:00]] 版)
[45] [CITE@en[OAuth 1 — OAuth]]
([TIME[2019-03-27 11:47:35 +09:00]])