MS_OAuth10 - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

OAuth 1.0

概要

移行メモ: 元ページは「概要 / 詳細」が空で、参考リンクのみだった。
ここでは移行にあたり、OAuth から参照されたときに
意味が通る程度の基本事項を補って記述する。

OAuth 1.0 は、リクエストへの署名によって保護される認可委譲プロトコル。

  • 2007 年に OAuth Core 1.0 として公開。
  • 2009 年にセッション固定攻撃が発見され、OAuth 1.0a で修正。
  • 2010 年に RFC 5849 として IETF 標準化。
  • OAuth 2.0 とは後方互換性が無い。

補足（現在の位置づけ）: 新規採用する場面はほぼ無い。
RFC 5849 は **RFC 6749（OAuth 2.0）によって廃止（obsoleted）**されている。

ただし、古い API を相手にするときに遭遇することがある
（Twitter API v1.1、一部の業務系 SaaS など）。
「読み解けること」が本ページの実用的な価値になる。

詳細

3-legged の流れ

# ステップ 内容
1 リクエスト トークンの取得 Consumer が Service Provider に要求（/request_token）
2 ユーザー認可 ユーザーをブラウザで Service Provider へ誘導し、承認させる
3 アクセス トークンへの交換 oauth_verifier を添えて交換（/access_token）
4 API 呼び出し 以降、アクセス トークンと署名でリソースにアクセス

補足: OAuth 2.0 の Authorization Code フローと
流れは似ているが、1 の「リクエスト トークンの事前取得」が余分である。
2.0 ではこの往復が省かれた。

署名（OAuth 1.0 の中核）

  • 署名方式: HMAC-SHA1 / RSA-SHA1 / PLAINTEXT
  • 署名対象: HTTP メソッド + URL + すべてのパラメタを
    正規化した「署名ベース文字列（Signature Base String）」
  • リプレイ対策: oauth_nonce（一度きりの値）と oauth_timestamp

補足（実装が難しかった理由）: 署名ベース文字列の生成規則が厳密で、

  • パラメタをキー名でソートして連結する
  • 二重に URL エンコードする箇所がある
  • Authorization ヘッダ / クエリ文字列 / ボディに散らばったパラメタを
    すべて集めて対象にする

といった具合で、1 文字ずれると署名が合わない。
しかもエラーは一律「署名が不正」としか返らず、切り分けが難しかった。

これが OAuth 2.0 で署名を捨てて
TLS に依存する設計へ舵を切った直接の理由である。

2-legged

ユーザーの認可を伴わない、Consumer と Service Provider の
サーバー間通信のための使い方（仕様上は明示されていないが慣例的に使われた）。
OAuth 2.0 の Client Credentials グラント種別に相当する。

参考

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️