MS_OAuth - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
OAuth 1.0 と OAuth 2.0 にページを分割しました。
補足（OAuth とは何か）: 一言でいえば
「パスワードを渡さずに、他人のサービスに自分のデータへのアクセスを許す」
ための仕組み（認可の委譲）である。「A というサービスに、B にある自分の写真を使わせたい。
でも B のパスワードは教えたくない」——これを解く。**認証（誰か）ではなく認可（何をしてよいか）**の仕様である点が要で、
認証に使うには OpenID Connect が必要になる。
- OpenID を使って Twitter や Ma.gnolia の API の認証委譲する方法を議論を開始。
- 2007/4 — OAuth のコミュニティが誕生。
- 2007/7 — OAuth の仕様の草案が完成。
- 2007/10 — OAuth Core 1.0 の最終草案がリリース。
- 2008/11 — 第 73 回の IETF 会合で OAuth の非公式会合も開かれ、
IETF に OAuth プロトコルを提案するかどうかを議論。 - 2009/4/23 — OAuth 1.0 のセキュリティ問題が判明。
この問題は、OAuth 1.0a で修正された。
補足: このセキュリティ問題は
「セッション固定攻撃（Session Fixation）」で、
攻撃者が取得したリクエスト トークンを被害者に承認させると、
攻撃者のアカウントに被害者のリソースが結び付いてしまうもの。
1.0a ではoauth_verifierを導入して修正された。
同種の問題は OAuth 2.0 でもstateパラメタで対処している。
- OAuth 1.0 とは後方互換性を持たない。
- 次世代の OAuth プロトコルとして、2012 年に RFC として発行された。
補足（最新化）: OAuth XYZ とその対抗案 OAuth TxAuth は統合され、
GNAP（Grant Negotiation and Authorization Protocol / RFC 9635, 2024）
として標準化された。ただし GNAP は OAuth 2.0 の後継ではなく別系統であり、
現時点で普及はしていない。
実務上の「次」は OAuth 2.1 の方である。
- HTTPS を必須にし、署名をなくし、Token 取得も簡略化
- Access Token のみでリソース取得が可能に
- Web アプリも含め、4 つの Client Profile を仕様化
- Web サーバ（Web Server）— Web アプリケーション
- User Agent ベースアプリケーション — WWW ブラウザ上の JavaScript
- ネイティブアプリ（Native Application）— モバイルやデスクトップアプリ
（ガイドライン程度しか定義されていない） - 自立クライアント（Autonomous）— 既存の認証フレームワークと
SAML などのプロトコルを使って連携する場合のフロー。
補足（「署名をなくした」ことの功罪）: OAuth 1.0 は
リクエストごとに署名していたため、
- 通信路が平文でも改ざん・なりすましを検知できた
- しかし実装が難しく（署名ベース文字列の正規化が鬼門）、普及の障害になった
2.0 は署名をやめて TLS に全面的に依存する設計にし、
実装の敷居を大きく下げた。これが普及の決め手になった一方、
「トークンを持っている者が使える（Bearer）」
という弱さを抱えることになった。その反省から、後に mTLS / DPoP といった
「送信者制約トークン（記名式）」の仕様が追加されている
（OAuth 2.0 のトークンを参照）。
OAuth 2.0 と OpenID Connect の違い
-
Token が JWT アサーション形式で署名（必要なら暗号化）される。
-
新しく、Hybrid Flow が追加されている。
| OAuth 2.0 | OpenID Connect |
|---|---|
| Authorization Code グラント種別 | Authorization Code Flow |
| Implicit グラント種別 | Implicit Flow |
| 上記を組合せたようなグラント種別 | Hybrid Flow |
- コレ以外にも、多数のオプションが追加されている。
移行メモ: 元ページは「Token が JWT アサーション形式で
暗号化・署名される」としていたが、
OIDC の ID トークンで**必須なのは署名（JWS）**であり、
暗号化（JWE）はオプションである（JWTを参照）。補足（本質的な違い）: 表面的なフローの差より重要なのは、
OIDC は「誰がログインしたか」を RP に伝える手段（ID トークン）を
定義したという点である。
OAuth 2.0 のアクセス トークンは「API を叩く権限」でしかなく、
それを認証の証明に使うのは誤りである
（他所で盗んだトークンかもしれない）。
- OAuth - Wikipedia
https://ja.wikipedia.org/wiki/OAuth - 初心者のためのOAuth — OAuthの基本のキ | Rriver
https://parashuto.com/rriver/development/learning-oauth-basics - How is OAuth 2 different from OAuth 1? - Stack Overflow
http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 - IETF106参加記録 - OAuthの未来｜株式会社レピダム
https://lepidum.co.jp/blog/2019-12-03/future-of-oauth/
- デジタル・アイデンティティ技術最新動向（1）：「OAuth」の基本動作を知る
http://www.atmarkit.co.jp/ait/articles/1208/27/news129.html - OAuth 2.0でWebサービスの利用方法はどう変わるか
http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth