ユーザの承認操作なしでアプリケーション連携を実現するOAuth拡張仕様

2026年04月01日水曜日

【この記事を書いた人】
四谷兼三

IIJ 技術研究所技術開発室所属。次世代認証・認可関連技術の研究に取り組んでいます。

「ユーザの承認操作なしでアプリケーション連携を実現するOAuth拡張仕様」のイメージ

CONTENTS

はじめに

OAuthは、アプリケーションが他のアプリケーションのデータにアクセスするための権限を、安全に付与するための仕組みです。アクセス権を付与するためには、通常、そのデータの所有者（＝ユーザ）による承認操作が必要です。しかし、最近、この承認操作を伴わずにアクセス権を付与する仕組みの整備が進んでいます。今、話題のAIエージェントの普及も、この動きを加速させる要因のひとつです。

この記事では、そのような仕組みを実現する、以下の3つのOAuth拡張仕様を紹介します。

RFC 8693 – OAuth 2.0 Token Exchange —— 承認操作なしで、既存のトークンと新たなトークンを交換
OAuth Identity and Authorization Chaining Across Domains —— 異なるドメイン間でも、トークンの交換を実現
Identity Assertion JWT Authorization Grant —— エンドユーザではなく、IT管理者がアクセス権を付与

RFC 8693 – OAuth 2.0 Token Exchange

API呼び出しの連鎖

あるAPIが別のAPIを呼び出し、そのAPIがさらにまた別のAPIを呼び出す、というAPI呼び出しの連鎖は珍しくありません。例えば、クライアントがフロントエンドAPIにリクエストを送り、そのAPIがバックエンドAPIを数珠つなぎで呼び出すといった構成が典型です。ここで問題になるのが、バックエンドのAPIへのアクセスをどう制御するか、です。

まず、APIキーのような事前に発行したクレデンシャルを使用してAPIを認証するパターンが考えられます。 APIの引数やHTTPヘッダーなどでユーザIDを指定するようにすれば、特定のユーザのデータへのアクセスが実現できます。しかし、このパターンは、呼び出し元に全ユーザのデータへのアクセスを許可することが前提となります。呼び出される側のAPIは渡されたユーザIDを信じるしか無く、そのアクセスがデータの所有者（＝ユーザ）の承認に基づくものか検証できません。万が一、悪意ある侵入を許してAPIキーを奪取された場合、任意のユーザのデータへのアクセスを防ぐ手段がありません。

OAuthでは、このような問題に対処するため、APIキーのような静的なクレデンシャルではなく、アクセストークンを使用します。アクセストークンは、特定のユーザのリソースへの限定的なアクセス権を表すトークンで、リソースの所有者の承認に基づき、認可サーバと呼ばれるサーバが発行します。アクセストークンには「誰のリソースに」「どの範囲で」アクセスできるか紐付いているため、APIキーのように任意のユーザのデータにアクセスできてしまう問題を回避できます。

では、すべてのAPIで同じアクセストークンを使えるようにするのはどうでしょうか。フロントエンドAPIが、クライアントが送ってきたアクセストークンを流用してバックエンドAPIにアクセス可能になりそうです。しかし、このパターンはOAuthを安全に使う上でのガイドラインであるRFC 9700 – Best Current Practice for OAuth 2.0 Securityにて非推奨となっています。なぜなら、アクセストークンが漏洩した場合のリスクが大きいからです。アクセストークンに付与する権限は必要最小限にすべきとされており、アクセス可能な対象は原則として単一のリソースに限定すべきです。したがって、各APIごとに別々のアクセストークンを使用する必要があります。

となると、APIを呼ぶAPIは新たなアクセストークンを取得せねばなりません。 OAuthはアクセストークンを発行する方式をいくつか定義していますが、その代表がAuthorization Code Grantと呼ばれる方式です。アプリケーション連携の設定中に画面がリダイレクトされ、「○○へのアクセスを許可しますか？」といった承認画面が表示される、おなじみの方式です。しかし、この方式はバックエンドAPIのアクセストークン発行には向いていません。承認を得るためにはユーザとの対話が必要ですが、通常、バックエンドAPIはユーザと直接、対話できないからです。

Security Token Service（STS）

このような課題を解決する手段が、Security Token Service（STS）という概念です。 STSとは、セキュリティトークン（アクセストークンなど）を検証し、それと引き換えに新たなセキュリティトークンを発行するサービスです。 STSを使うと、クライアントは異なるリソースや異なるセキュリティドメイン向けのトークンを動的に取得できます。

前述の例に当てはめると、フロントエンドAPIはクライアントから受け取ったアクセストークンをSTSに提示して、バックエンドAPI用のアクセストークンを取得できるようになります。元のアクセストークンに紐付けられていたユーザIDや権限といった情報は、STSが検証した上で次のアクセストークンに引き継がれるので、APIキーを用いたパターンのようにユーザIDを信頼できない形で受け渡す必要がありません。

OAuthにSTSの概念を導入した実装としては、Microsoft Entra IDが提供しているOAuth 2.0 On-Behalf-Of flow（OBOフロー）があります。 OBOフローは、まさにこのユースケースのために設計されたもので、あるAPIが受け取ったアクセストークンを提示して、後段のAPIにアクセスするための新たなアクセストークンを取得できます。ただし、OBOフローはMicrosoft Entra IDに固有の実装であり、標準化された仕様ではありません。

Token Exchangeの概要

RFC 8693 – OAuth 2.0 Token Exchangeは認可サーバにSTSの役割を持たせるためのOAuth 2.0拡張仕様です。この記事では以降、この仕様をToken Exchangeと呼びます。

Token Exchangeは汎用的なセキュリティトークン交換フレームワークとして設計されています。交換元や交換先のトークンの具体的な形式や内容、信頼モデルについては規定しておらず、個々の実装に委ねています。

Token Exchangeによって、クライアントは認可サーバにアクセストークンを提示して、別のアクセストークンを取得できるようになります。このトークン交換はクライアントと認可サーバ間のやり取りで完結するので、ユーザによる対話的な承認操作は不要です。また、トークン交換で発行されたトークンを交換元として、さらに別のトークンと交換することもできます。これらの特徴により、バックエンドにおけるAPI呼び出しの連鎖を安全に実現できます。

Token Exchangeのフロー

以下の図はToken Exchangeのフローを簡略化したものです。

Token Exchangeのフローを示すシーケンス図

クライアントは既にAPI A用のアクセストークンAを取得しているものとします。

クライアントは、API AのAPIを呼び出します。
API Aは、認可サーバにToken Exchangeリクエストを送信します。このとき、交換元のトークンとしてアクセストークンAを、アクセス先としてAPI Bを指定します。
認可サーバは、Token Exchangeリクエストを検証し、API B用のアクセストークンBを発行します。
API Aは、API BのAPIを呼び出します。
API Bは、APIのレスポンスを返します。
API Aは、APIのレスポンスを返します。

もし、API Bがさらに後段のAPIを呼ぶ場合、同様に連鎖できます。

API呼び出し経路の追跡

A -> B -> C、とAPIの呼び出しが連鎖する場合、Cからは自分を呼び出したのがBであることはわかるものの、通常、その背後にいるAのことはわかりません。 Token Exchangeは、このAPI呼び出しの連鎖を追跡できる仕組みをプロトコルレベルでサポートしています。

具体的には、発行するトークンに「このトークンを使ってAPIを呼び出すのは誰か」という情報を記録します。トークン交換時にはその情報を引き継ぎ、入れ子にして新しいトークンに記録します。これにより、呼び出された後段のAPIは「誰が」「どのAPIを経由して」アクセスしてきたか把握できるようになります。複雑なAPIの呼び出し経路を記録することは、監査やトラブルシューティングなどにおいて非常に有用です。

OAuth Identity and Authorization Chaining Across Domains

複数のドメインにまたがるトークン交換

Token Exchangeの説明で使用した例は、単一の組織（ドメイン）内でのケースでした。次は、複数のドメイン間にまたがったトークン交換について考えます。

まず、そのような仕組みが求められる理由を、CI/CDのサービスを例に考えてみます。 CI/CDサーバで実行されたビルドの成果物を、外部のクラウドプロバイダにデプロイしたりするケースです。従来は、各サービスでAPIキーなどを事前に発行し、それをCI/CDサービス側に保存しておくのが一般的でした。しかし、この方法にはAPIキーの漏洩リスクや定期的なローテーションの手間といった負担が伴います。

そこで求められるようになったのが、静的なAPIキーに依存しない、ドメイン間連携による動的なトークン交換です。元のドメイン（CI/CDサービス側）で発行されたトークンを、外部ドメインの認可サーバに提示し、対象リソース用の新しいトークンと動的に交換します。これにより、CI/CDサーバ上でのビルド成功時にオンデマンドでクラウドプロバイダのアクセストークンを取得できるようになり、煩わしいAPIキーの管理から解放されます。実際の例だと、GitHub Actionsでは2021年から、動的なトークン交換によるクラウドプロバイダへのデプロイが利用可能になり、APIキーなどをGitHub側に保存することなく、クラウドサービスと安全に連携できるようになりました。

GitHub Actionsとクラウドプロバイダ間のトークン交換は、各クラウドプロバイダが提供するそれぞれ異なる方式で実現されています。例えば、Amazon Web Services（AWS）は独自のSTS APIによる方式、Google CloudはToken Exchangeを使用した方式を採用しています。そのため、ワークフローから呼び出すトークン交換用のGitHub Actionは、各社が自社の仕様に合わせたものをそれぞれ提供しています。また、Google CloudではToken Exchangeを採用していますが、同仕様は汎用的なトークン交換の仕組みであり、異なるドメイン間の安全な連携方法までは規定されていません。 Google Cloud側で独自の検証の仕組みを構築し、プロトコルとして足りない部分を補完することでカバーしています。このように、異なるドメイン間で安全にトークンを交換する仕組みの標準が存在しないため、交換を要求する側と受け入れる側の双方で、相手に合わせた対応が必要になっているというのが現状です。

Identity Chainingの概要

現在、IETFで策定中のドラフト、OAuth Identity and Authorization Chaining Across Domainsは、このようなドメイン間連携の標準化を目指す仕様です。この記事では以降、この仕様をIdentity Chainingと呼びます。

Identity Chainingは、Token Exchange（もしくは代替となるSTS）と、JWT Authorization Grant（後述）を組み合わせたフレームワークです。異なるドメインにまたがるリクエストにおいて、「誰が」「どんな権限で」「どこを経由して」アクセスしているかという情報を保持したまま、安全にトークンを交換する方法を定義します。ドラフトではIdentity Chainingのユースケースとして、これらの情報を保持したまま、マルチクラウド環境やオンプレミスとクラウドが混在するハイブリッド環境にまたがるワークロードのアクセスを制御する例などが挙げられています。

Identity Chainingは汎用的なフレームワークとして設計されています。交換元となるトークンの仕様や、ドメイン間でのユーザアカウントのマッピングをどうするか、といった具体的な詳細は、個々のユースケースに応じて定義する必要があります。

JWT Authorization Grant

JWT Authorization GrantはRFC 7523 – JWT Profile for OAuth 2.0 Client Authentication and Authorization Grantsにて定義されているアクセス権の付与方式です。アクセストークンの取得にJSON Web Token（JWT）形式のアサーション（以降、JWTアサーションと呼びます）を使用します。 OAuthにおけるアサーションとは、ドメインをまたいでアイデンティティやセキュリティ情報を共有するための、情報のパッケージです。

JWT Authorization Grantで使用するJWTアサーションは通常、Identity Provider（IdP）が発行します。 IdPとは、ユーザの認証を行い、ID情報を一元管理するサービスのことです。 JWTアサーションには発行者、つまりIdPの署名が含まれています。クライアントはアクセストークン発行リクエストとして、このJWTアサーションを認可サーバに提示します。認可サーバは署名を検証し、そのリクエストが信頼できる発行元によるものであるか確認します。検証に成功し、さらに、JWTアサーション内で指定されているアクセス権限の要求が事前に設定されているポリシーで許可されていれば、アクセストークンを発行します。

ユーザとの対話的な承認ステップなしで、トークン（JWTアサーション）を元に新たなトークン（アクセストークン）を発行するという点では、Token Exchangeと似ています。しかし、その目的やカバーする領域は異なります。 Token Exchangeはあるトークンを別のトークンと交換する汎用的なフレームワークで、API呼び出し経路の追跡など、STSに求められる機能を広くカバーしています。しかし、異なるドメイン間で安全に連携するための信頼モデルは規定されておらず、ドメインを越えた連携の仕組みが欠けています。一方、JWT Authorization GrantはJWTアサーションと引き換えにアクセストークンを発行するだけのシンプルな仕様です。単体でSTSとして使うには機能が足りませんが、JWTアサーションの署名によって発行元の信頼を担保できるため、異なるドメインを安全につなぐことには長けています。

Identity Chainingはこの2つを組み合わせることで、それぞれの長所を活かしたドメイン間連携を実現しています。

Identity Chainingのフロー

以下の図はIdentity Chainingのフローを簡略化したものです。

Identity Chainingのフローを示すシーケンス図

ドメインAのクライアントは、既にドメインA内で何らかのトークン（アクセストークンやIDトークンなど）を取得しているものとします。また、ドメインBの認可サーバは、事前にドメインAの認可サーバの公開鍵を取得しているものとします。

ドメインAのクライアントは、ドメインAの認可サーバにToken Exchangeリクエストを送信します。このとき、交換元のトークンとして既に持っているトークンを指定し、アクセス先としてドメインBの認可サーバを指定します。
ドメインAの認可サーバは、リクエストを検証し、ドメインBの認可サーバ向けのJWTアサーションを発行します。このとき、ステップ1で指定されたアクセス先の値（ドメインBの認可サーバ）を、JWTアサーションに宛先として埋め込みます。このJWTアサーションには、ドメインAの認可サーバの署名が付与されています。
ドメインAのクライアントは、取得したJWTアサーションをドメインBの認可サーバに提示し、JWT Authorization Grantによるアクセストークンの発行を要求します。
ドメインBの認可サーバは、ドメインAの認可サーバの公開鍵を使用してJWTアサーションを検証し、アクセストークンを発行します。
ドメインAのクライアントは、取得したアクセストークンを使ってドメインBのAPIを呼び出します。
ドメインBのAPIは、APIのレスポンスを返します。

このように、Identity ChainingはToken ExchangeとJWT Authorization Grantによる2段階のトークン交換ステップで構成されています。 Token Exchangeによって、元のトークンに含まれていたユーザのID情報やアクセス権限を、アクセス先ドメイン向けのJWTアサーションとしてパッケージングします。 API呼び出し経路もJWTアサーションに埋め込めるので、連鎖するAPI呼び出しの追跡もできます。 JWT Authorization Grantによって、このJWTアサーションを異なるドメインへ安全に受け渡します。この2段階の仕組みによって、アイデンティティと認可の情報を維持したまま、異なるドメインのAPIへのアクセスを実現しています。

また、このフロー全体を通じて、ユーザによる対話型の承認は一切不要です。

Identity Assertion JWT Authorization Grant

エンタープライズにおけるアプリケーション連携

エンタープライズ環境では、多数のSaaSアプリケーションが企業のIdPを通じたシングルサインオン（SSO）で統合されているのが一般的です。 SSOにより、ユーザは一度の認証で、許可されたすべてのアプリケーションにログインできます。しかし、SSOが可能にするのはログインだけです。あるアプリケーションから別のアプリケーションのAPIを呼び出す場合、SSOによるログインとは別に、OAuthを使ったアプリケーション連携が必要になります。しかし、エンタープライズ環境における、従来のOAuth（Authorization Code Grant）の使用には課題があります。

まず、ユーザの操作体験の問題があります。 Authorization Code Grantでは、ユーザはアプリケーション連携の設定時に認可サーバに画面をリダイレクトされ、手動で承認せねばなりません。連携させるアプリケーションの組み合わせが増えるたびにその操作が生じます。新入社員は入社初日にその操作を何度も繰り返すことになります。そもそも、会社が契約したアプリケーションで、業務に必要なアプリケーション連携なら、承認画面で「いいえ」を選択することはないでしょう。

もう一つの深刻な問題は、IT管理者による管理が困難になることです。 Authorization Code Grantによる連携は、ユーザ個人と各アプリケーションの間で直接、結ばれます。そのため、IdPからはアプリケーション間の連携を追跡できません。 IT管理者からすると、どのアプリケーションがどのリソースへのアクセス権を持っているのか、管理が難しくなります。アクセス権の棚卸しや一括失効も容易ではありません。これは、エンタープライズにおいては受け入れがたいガバナンスの欠如を招きます。

ID-JAGの概要

これらの課題を解決するために、現在IETFで議論を進められているドラフトが、Identity Assertion JWT Authorization Grantです。略してID-JAGと呼ばれます。（または、Cross-App Access（XAA）とも呼ばれます。この記事ではID-JAGで統一します）。

ID-JAGはIdentity ChainingをエンタープライズのSSO環境向けに特化させた仕様です。その最大の特徴は、アプリケーション連携にIdPを必ず仲介させるという点にあります。従来はユーザを介して、アプリケーションと認可サーバが直接やり取りするモデルでしたが、ID-JAGでは企業が管理するIdPにアクセス権の管理を集中させるアプローチをとります。 SSOがログインを一元管理するように、ID-JAGはアクセス権の付与を一元管理します。

このアプローチにより、先に挙げた課題を解決します。アプリケーション連携の設定はIT管理者が一括で行うので、個々のユーザが承認操作を求められることはなくなります。トークン交換に必ずIdPが介在するため、IT管理者はIdPを通じて、どのアプリケーションが、誰の代理として、どのリソースにアクセスしているか、を一元的に管理できるようになります。また、アクセス権の設定をユーザ個人の判断に委ねるのではなく、「このアプリケーションには読み取り権限しか与えない」といったセキュリティポリシーをIT管理者が事前に定義し、強制することが可能になります。

ID-JAGはまだドラフト段階の仕様ですが、仕様策定を主導しているOktaがEarly Accessとしてサービスを提供しています。

ID-JAGのフロー

ID-JAGはIdentity ChainingをエンタープライズSSO環境に特化したものなので、フローも基本的には同じです。

以下の図は、ID-JAGのフローを簡略化したものです。

ID-JAGのフローを示すシーケンス図

この例では、OpenID ConnectによるSSOで取得したIDトークンを交換元に使用していますが、リフレッシュトークンやSAMLアサーションを使うケースも想定されています。

ドメインAのクライアントは、SSOを使用したユーザの認証をIdPに要求します。
認証に成功したら、IdPの認可サーバはクライアントにユーザの識別情報としてIDトークンを発行します。
ドメインAのクライアントは、IdPの認可サーバにToken Exchangeリクエストを送信します。このとき、交換元のトークンとしてIDトークンを指定し、アクセス先としてドメインBの認可サーバを指定します。
IdPの認可サーバは、リクエストを検証し、ドメインBの認可サーバ向けのJWTアサーションを発行します。このとき、ステップ3で指定されたアクセス先の値（ドメインBの認可サーバ）を、JWTアサーションに宛先として埋め込みます。このJWTアサーションには、IdPの認可サーバの署名が付与されています。
ドメインAのクライアントは、取得したJWTアサーションをドメインBの認可サーバに提示し、JWT Authorization Grantによるアクセストークンの発行を要求します。
ドメインBの認可サーバは、IdPの公開鍵を使用してJWTアサーションを検証し、アクセストークンを発行します。
ドメインAのクライアントは、取得したアクセストークンを使ってドメインBのAPIを呼び出します。
ドメインBのAPIは、APIのレスポンスを返します。

ID-JAGでは、SSOによって各アプリケーションとIdPの間に既に確立されている信頼関係を、そのまま活用します。例えば、JWTアサーションの検証に必要なIdPの公開鍵は、SSOでのIDトークンの検証に普段から使用しているものです。そのため、ID-JAGのために、新たなドメイン間の信頼関係を確立する必要がありません。

また、この一連のフローの中で、ユーザの承認操作が必要なのは、最初のSSOによるログインのみです。以降のステップでは一切不要です。

AIエージェントとID-JAG

近年、急速に普及しているAIエージェントにとっても、ID-JAGは重要になる技術です。

例えば、チャットメッセージの検索、プロジェクト管理ツールでのチケット作成、クラウドストレージからのファイルダウンロードなど、AIエージェントはユーザの代理として様々なSaaSのAPIを呼び出してタスクを実行します。エンタープライズ環境でも、業務効率化のため、その利用が推進されるでしょう。

しかし、従来のOAuth（Authorization Code Grant）によるアクセストークン発行は、このケースに向いていません。 Authorization Code Grantでは、アプリケーション連携のたびにユーザによる対話的な承認が必要です。ところが、AIエージェントがどのアプリケーションのAPIを呼び出すかは実行時に動的に決まるため、必要なすべての連携について事前に承認を済ませておくことができません。そのため、AIエージェントが新たなアプリケーションにアクセスするたびに、ユーザが承認操作を行わなければなりません。これではAIエージェントの自律的な動作が中断され、利便性が大きく損なわれます。また、複数のアプリケーションを横断してアクセスする場合、個々のアクセスは正当であっても、組み合わさった結果、本来意図されていないアクセス（社外秘情報を公開スペースにアップロードするなど）が発生するリスクもあります。各アプリケーションとの連携をユーザ個人の承認に委ねてしまうと、こうしたアクセスの連鎖がIT管理者から確認できなくなり、深刻な問題を引き起こします。

ID-JAGは、これらの問題の解決策となります。 AIエージェントも他のSaaSアプリケーションと同様に、ユーザはSSOでログインして利用します。ログイン後、AIエージェントはIT管理者が事前に設定したポリシーに基づき、各アプリケーションにアクセスできるようになります。アクセストークンは都度、オンデマンドで発行される短寿命のものであり、権限も必要最小限に限定されます。そして、すべてのトークン発行がIdPを経由するため、IT管理者はAIエージェントがどのリソースにどのような権限でアクセスしているか、一元的に管理できます。

このようなユースケースのサンプルとして、ID-JAGのドラフトにはLLMエージェントが企業の外部ツールにアクセスする例が記載されています。また、Oktaはブログ記事でAIエージェントがユーザの代理としてMCPサーバ経由で保護されたリソースにアクセスするシナリオを解説しています。

おわりに

ユーザによる対話的な承認操作を伴わずにアクセストークンを取得する方法として、Token Exchange、Identity Chaining、ID-JAGという3つのOAuth拡張仕様を紹介しました。これらは、同一ドメイン内のトークン交換から、異なるドメイン間のトークン交換へ、さらにエンタープライズSSO環境への特化と、段階的に積み重なる関係にあります。

いずれの仕様も、ユーザの承認操作を省略する代わりに、認可サーバやIdPによるポリシー評価を経由させることで、セキュリティを維持しています。承認操作が不要とは、誰でもアクセスできるという意味ではありません。ユーザによる承認から、ポリシーによる統制へ、アクセス制御の判断主体を移すということです。

SaaSアプリケーション間の連携やAIエージェントの普及が進む中、これらの仕様が今後さらに注目を集めていくと考えられます。

参考リンク

四谷兼三

2026年04月01日水曜日

IIJ 技術研究所技術開発室所属。次世代認証・認可関連技術の研究に取り組んでいます。

ユーザの承認操作なしでアプリケーション連携を実現するOAuth拡張仕様

はじめに