[4] OAuth 1.0 は、 Web API へのアクセス権限に関するプロトコルです。

[5] 非互換で名前以外まったく違ったプロトコルである OAuth 2.0 によって形式的には廃止され、新しい実装はそちらを採用することが一般的になっていますが、 依然として OAuth 1.0 を使っている実装も少なくありません。

仕様書

[6] OAuth 1.0 は3回正式な仕様書として出版されています。技術的にはほぼ同じ内容ですが、 若干の違いはあります。

  1. [7] OAuth Core 1.0 ( 版) http://oauth.net/core/1.0/ (2007年10月)
  2. [8] OAuth Core 1.0a ( 版) http://oauth.net/core/1.0a/ (2009年6月)
  3. [9] RFC 5849 - The OAuth 1.0 Protocol ( 版) https://tools.ietf.org/html/rfc5849 (2010年4月)

[10] 最初の2つは OAuth Core Workgroup により出版されましたが、その後 IETF に移管 >>9 され情報提供RFCとして発行されました。 現在最初の2つには RFC 5849 を参照するよう注意書きが追加されています。

[11] 最初の版にはセッション固定攻撃に対する脆弱性があったため、 1.0a で修正されています。

[38] 「Core 1.0」→「Core 1.0a」→「1.0」とわけのわからないバージョンアップが行われたため、 どの版を指しているかに若干の混乱も見られました。

用語

[14] RFC 5849 とそれ以前で用語一式が違っています。 一般には歴史がある旧来の用語が使われているケースが多いようです。

[15] 標準化団体が変わると用語が変わるのはよくあることです。 普及している用語を変えられると結局新旧両方覚えないといけなくなるので面倒な話です。。。

プロトコル

[21] OAuth 1.0 は、

... で構成されています。

[29] その他次の概念があります。

[44] OAuth 1.0 の構成要素

[41] 他に次の拡張仕様があります。拡張仕様は必ずしも実装されていません (それぞれの項を参照)。

[43] OAuth 1.0 の拡張

リダイレクトによる認可

[22] リダイレクトを使った認可authorizationは、 次の3段階で行います >>20。

  1. [23] temporary credentials要求: クライアントが、鯖から temporary credentials (識別子と共有秘密) を得ます。
  2. [24] 資源所有者認可: 資源所有者が、鯖に対して、 (temporary credentials によって識別される) クライアントのアクセス要求に応えることを認可します。 (資源所有者はこのエンドポイントにリダイレクトされてきます。)
  3. [25] トークン要求: クライアントが、 temporary credentials を使って鯖から token credentials を得ます。

[27] 第2段階は資源所有者が Webブラウザー等でアクセスすることが期待されています。 第1段階と第3段階はクライアントから鯖に直接アクセスすることが期待されています。

[26] この3段階のエンドポイントの URL を鯖はクライアントに広告する必要があります >>20。 しかしその方法は規定されていません >>20。 その URL は query を含んでいても構いませんが、 oauth_ から始まる引数を含んではなりません >>20。

[33] 一般的には当該 Web API のドキュメントの類で自然言語によりエンドポイントと適用できる引数などを説明することが多いようです。
O
資源所有者
C
クライアント
S
鯖
O -> C
OAuth 処理開始
C -> S
※一時credentials要求 (POST)
S -> C
※一時credentials要求への応答 (200 一時credentials発行)
C -> O
※資源所有者認可へのHTTPリダイレクト
O -> S
資源所有者認可の要求 (GET)
S -> O
資源所有者認可の確認
O -> S
資源所有者認可の承認の通知
S -> O
※コールバック URL へのHTTPリダイレクト (検証符号発行)
O -> C
コールバック URL への要求
C -> S
※トークン要求 (POST)
S -> C
※トークン要求への応答 (200 トークンcredentials発行)
C -> O
OAuth 処理完了
[18] OAuth としては「※」の部分を規定しています。それ以外の部分は相互運用性に直接影響しないので、 具体的にどう動作させるかは実装依存になっています。

[30] Google や Twitter はこの方式を 3-legged OAuth >>31, >>39 と呼んでいました。

[32] この方式は OAuth 2.0 の承諾型のうち認可符号に相当します。 ただし両者のフローは大きく異なっていて、互換性は全くありません。

認証された要求

[34] HTTP認証では、クライアントが要求に credentials を含めて送信し、鯖がそれを受け入れるか判断します。 OAuth 1.0 でも HTTP要求に credentials を含めます。 OAuth 1.0 では、 クライアントを表すクライアントcredentialsと、 資源所有者を表すトークンcredentialsを(両方共)使います。

[35] 詳しくは次の各項を参照。

[36] auth-scheme OAuth は、 OAuth 1.0 の credentials や challenge を表します。 用法については、引数 (OAuth 1.0) と challenge を参照してください。

[37] この値は RFC 5849 で規定されました。 RFC 723x で新設された IANA登録簿には RFC 7236 で登録されています >>2。

[40] OAuth 2.0 において auth-scheme Bearer とするべきところ、 OAuth を使う実装もあります。

Bearer 参照。

XOAUTH

[1] Gmail Platform — Google Developers ( ( 版)) https://developers.google.com/gmail/oauth_protocol

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] draft-ietf-kitten-sasl-oauth-16 - A set of SASL Mechanisms for OAuth ( ( 版)) https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-16

関連

[12] 元々 OAuth は OpenID とは異なるものでしたが、 OAuth を使ってログイン機能を実装するのが流行し、結果的にそれまでの (あまり普及していなかった) OpenID によるログイン機能を置き換えるものとなりました。

[13] xAuth は OAuth 1.0 から派生したプロトコルです。

メモ

[16] 特定のクライアントを許可している Twitter ユーザーの Token Credentials を入手する攻撃 - ひだまりソケットは壊れない ( ( 版)) http://vividcode.hatenablog.com/entry/twitter-oauth-vulnerability

[19] oauth - API needz authorized? - Google Project Hosting ( 版) https://code.google.com/p/oauth/

[42] RFC 7628 - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth ( 版) https://tools.ietf.org/html/rfc7628

[45] OAuth 1 — OAuth () https://oauth.net/1/