MS_TransactionalAuthorization - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Transactional Authorization(XYZ)

概要

  • 名前の変遷（同じものです）

    Transactional Authorization → XYZ (oauth.xyz) → TxAuth (IETFメーリングリスト) → GNAP (Grant Negotiation and Authorization Protocol)

  • OAuth XYZ(3.0) とも呼ばれる。

  • OAuth の複雑性に対処するため、

    • フロントチャネルを可能な限り使わない。
    • 認可に関連する情報をトランザクションに集約していく。

    という方法を提案。

  • RFC 化は 2024 年に完了したが、実際の普及はこれから
    （と言うがスルーされてる感もある）

    • ゼロからの実装が必要なため、「段階的移行」ができない。これが普及の大きな壁。
    • 現場の開発者が「今日困っていること」は OAuth 2.0 の拡張で大体対処できてしまう。
    • GNAP はアーキテクチャとして正しいのに、
      タイミングとエコシステムの慣性に負けている典型例になりつつある

補足（RFC 番号）: GNAP は **RFC 9635（GNAP コア プロトコル）**と
**RFC 9767（Resource Server Connections）**として発行された。

動機

様々なOAuth 2.0 拡張を、

  • 同じような問題を解決するために
  • 同じような不完全なコンポーネントを利用する。

と表現している。

...確かに、最近、

  • 仕様が多過ぎると思い始めてきた。
  • また、Client が簡単に実装できなくなってきた。

と言う問題が目に付き始めた。

補足（著者の実感を裏付ける数）: 本 Wiki の
OAuth 2.0 拡張配下だけでも
PKCE / DPoP / JAR / JARM / PAR / RAR / mTLS / Token Introspection /
Token Revocation / Device Authorization Grant / CIBA …と
十数の仕様が並ぶ。
GNAP はこれらを個別の拡張ではなく 1 つのプロトコルの中に
折り込み直すという発想であり、
「仕様が多過ぎる」という本節の実感がそのまま設計動機になっている。

特徴

  • OAuth 2.0 と互換性は無い。

  • トランザクションモデルをベースとした認可プロトコル

  • OAuth XYZ は初期 OIDC の OpenID ABC を踏襲しているという説がある。

  • 英語の文章には

    「XYZ プロトコルは、情報を渡すために
    フロントチャネルを最小限に利用しようとしています。」

    とある。

  • これは、

    「色々とバックエンドに押し込むため、フロントエンドには、
    interact (interact_handle) しか露見しないからセキュア。」

    と言う事らしい。

  • 3D Secure（クレカ決済などで使用される本人認証サービス）
    でも、同じようなフローになっているらしい。

詳細

  • transaction (handle) と、
    interact (interact_handle) を使用する。

  • これにより、

    • 様々なフローの、
    • 色々なやり取りを

    バックエンドに押し込むことが出来る。

handle

transaction (handle)

バックチャンネルからトランザクション開始要求を行う。
これにより、transaction (handle) が発行され以降これを使用して処理する。

interact (interact_handle)

クライアントとの interact 部分には、interact_handle を使用する。
これにより、フロントチャネルの使用を最小限にしている。

補足（OAuth 2.0 との対比）: OAuth 2.0 では、
認可リクエストのパラメタをすべてブラウザの URL に載せて
認可サーバへ渡す（フロントチャネル）。
このため state / nonce / redirect_uri の検証や PKCE といった
「URL に載せたものを守る」ための仕組みが次々に必要になった。
GNAP はまずバックチャネルで要求を投げて handle を得て、
ブラウザには handle だけを通す。
守るべきものをフロントチャネルに置かないという設計であり、
後から PAR（Pushed Authorization Requests）が
OAuth 2.0 側に同じ発想を持ち込んだ形になっている。

フロー

  • 様々なフローが XYZ で表現できるらしい。

  • サンプルとして、以下のフローが公開されている。

    • Authorization Code Flow
    • Device Flow
    • Client Credentials Flow
    • Resource Owner's Password Credentials / Assertion Flow

移行メモ（体裁）: 元ページでは上記の 4 つが
見出しのみで本文が書かれていなかったため、箇条書きに整理した。
著者による本文が加筆された場合は置き換えること。

参考

Tags: IT国際標準, 認証基盤, ASP.NET Identity, OAuth

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

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