1. はじめに
セキュリティトークンは、異種環境またはセキュリティドメイン間でアイデンティティおよびセキュリティ情報の共有を促進する情報のセットです。セキュリティトークンの例には、JSON Web Token (JWT) [JWT] および Security Assertion Markup Language (SAML) 2.0 アサーション [OASIS.saml-core-2.0-os] が含まれます。セキュリティトークンは通常、整合性を実現するために署名され、機密性を実現するために暗号化されることもあります。セキュリティトークンは、[RFC7521] のように、アサーションとして記述されることもあります。
セキュリティトークンサービス (STS) は、提供されたセキュリティトークンを検証し、応答として新しいセキュリティトークンを発行できるサービスであり、これにより、クライアントは異種環境またはセキュリティドメイン間のリソースに対して適切なアクセス資格情報を取得できます。Web サービスクライアントは、トークン交換のために STS と対話するプロトコルとして WS-Trust [WS-Trust] を使用してきました。WS-Trust は XML と SOAP を使用しますが、最新の Web 開発の傾向は RESTful (Representational State Transfer) パターンと JSON に向かっています。OAuth 2.0 認可フレームワーク [RFC6749] および OAuth 2.0 Bearer Tokens [RFC6750] は、サードパーティアプリケーションによる HTTP および RESTful リソースへのアクセスを認可するための一般的な標準として登場しました。従来の OAuth 2.0 の対話には、アクセストークンのリソース所有者認可の何らかの表現の交換が含まれており、これは実際には非常に有用なパターンであることが証明されています。ただし、その入力と出力は、セキュリティトークン交換フレームワークに完全に対応するには、現状のままでは制約が多すぎます。
本仕様は、クライアントが STS の役割を果たす認可サーバーからセキュリティトークンを要求および取得できるようにする、OAuth 2.0 を拡張するプロトコルを定義します。OAuth 2.0 と同様に、本仕様はクライアント開発者の単純さに焦点を当てており、HTTP クライアントと JSON パーサーのみを必要とします。これらは、最新の開発環境ではほぼ普遍的に利用可能です。本仕様で定義されている STS プロトコル自体は RESTful ではありません (STS は特に REST アプローチに適していません) が、RESTful システムでの作業に慣れている開発者になじみのある通信パターンとデータ形式を利用しています。
トークン交換リクエストの新しいグラントタイプと、トークンエンドポイントへのそのようなリクエストに関連する特定のパラメータは、本仕様によって定義されています。トークン交換レスポンスは、クライアントに情報を提供するためにここで定義されたいくつかの追加パラメータを含む、トークンエンドポイントからの通常の OAuth 2.0 レスポンスです。
トークンを交換するリクエストを行うエンティティは、トークン交換の対話のコンテキストではクライアントと見なされます。ただし、これはこのプロファイルの使用を従来の OAuth クライアントに制限するものではありません。たとえば、OAuth リソースサーバーは、保護されたリソースリクエストで受け取ったアクセストークンを、バックエンドサービスの呼び出しに含めるのに適した新しいトークンと交換するために、トークン交換中にクライアントの役割を担う場合があります。新しいトークンは、ダウンストリームサービス用により狭くスコープされたアクセストークンである場合もあれば、まったく異なる種類のトークンである場合もあります。
本仕様の範囲は、OAuth 2.0 を利用した STS スタイルのトークン交換のための基本的なリクエストおよびレスポンスプロトコルの定義に限定されています。委任セマンティクスを表現できるようにするいくつかの新しい JWT クレームが定義されていますが、トークン自体 (認可サーバーに提示されるトークンとクライアントが取得するトークンの両方) の具体的な構文、セマンティクス、およびセキュリティ特性は明示的に範囲外であり、実装が展開される可能性のある信頼モデルには要件が課されません。追加のプロファイルは、関係者および関与する信頼の具体的な性質に関するより詳細な要件を提供する場合があります。たとえば、トークンの署名や暗号化が必要かどうか、または所有証明 (proof-of-possession) スタイルのトークンが必要または発行されるかどうかなどです。ただし、そのような詳細は、多くの場合、個々の展開の特定のニーズに関して行われるポリシー決定であり、それに応じて構成または実装されます。
取得されたセキュリティトークンは、さまざまなコンテキストで使用される可能性がありますが、その詳細も本仕様の範囲外です。
1.1. 委任対なりすましセマンティクス
STS の一般的なユースケースの 1 つ (前のセクションで言及) は、リソースサーバー A がリクエストユーザー B に代わってバックエンドサービス C を呼び出せるようにすることです。ローカルサイトポリシーと認可インフラストラクチャによっては、A が独自の資格情報を使用して C にアクセスし、A が B に代わって行動していることを示す何らかの形式の注釈を付けることが望ましい場合 (「委任」) や、A に C への制限付きアクセス資格情報が付与されているが、認可されたエンティティとして B を引き続き識別する場合 (「なりすまし」) があります。委任となりすましは、複数の参加者が関与する他のシナリオでも有用な概念となる可能性があります。
プリンシパル A がプリンシパル B になりすます場合、A には、定義された権利コンテキスト内で B が持つすべての権利が与えられ、そのコンテキストでは B と区別がつきません。したがって、プリンシパル A がプリンシパル B になりすます場合、そのようなトークンを受け取るエンティティに関する限り、彼らは実際には B を扱っています。アイデンティティシステムのメンバーの一部は、なりすましが行われていることを認識している可能性がありますが、それは要件ではありません。すべての意図と目的において、A が B になりすましている場合、A はトークンによって認可された権利のコンテキスト内での B です。A が B になりすます能力は、トークンの内容または帯域外メカニズムによって、範囲または時間が制限されたり、1 回限りの使用制限があっても制限される場合があります。
委任セマンティクスはなりすましセマンティクスとは異なりますが、2 つは密接に関連しています。委任セマンティクスでは、プリンシパル A は依然として B とは別の独自のアイデンティティを持っており、B がその権利の一部を A に委任した可能性がある一方で、行われるアクションは B を代表する A によって行われていることが明示的に理解されています。ある意味、A は B の代理人です。
委任となりすましは、すべての状況を網羅しているわけではありません。たとえば、プリンシパルが自分自身のために直接行動している場合、委任もなりすましも行われません。ただし、これらはトークン交換で動作するより一般的なセマンティクスであるため、本仕様ではより直接的に扱われています。
委任セマンティクスは、通常、トークンの主要なサブジェクトと、そのサブジェクトがその権利の一部を委任したアクターの両方に関する情報を含めることで、トークンで表現されます。このようなトークンは、複数のサブジェクトに関する情報で構成されているため、複合トークンと呼ばれることがあります。通常、リクエストでは、「subject_token」はトークンが要求されている当事者のアイデンティティを表し、「actor_token」は発行されたトークンのアクセス権が委任されている当事者のアイデンティティを表します。認可サーバーによって発行された複合トークンには、両方の当事者に関する情報が含まれます。複合トークンが発行されるかどうかは、認可サーバーおよび適用可能なポリシーと構成の裁量によります。
複合トークンを表現する詳細、およびそのようなトークンが発行されるかどうかは、実装の詳細とトークンの種類によって異なります。JWT ではない複合トークンの表現は、本仕様の範囲外です。ただし、「actor_token」リクエストパラメータは、目的のアクターに関する情報を提供するための手段を提供し、JWT 「act」クレームは委任の連鎖の表現を提供できます。
1.2. 要件の表記と規則
本書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。これらがすべて大文字で表示される場合にのみ、このように解釈されます。
1.3. 用語
本仕様では、OAuth 2.0 [RFC6749] で定義されている用語「アクセストークンタイプ」、「認可サーバー」、「クライアント」、「クライアント識別子」、「リソースサーバー」、「トークンエンドポイント」、「トークンリクエスト」、「トークンレスポンス」、および JSON Web Token (JWT) [JWT] で定義されている用語「Base64url エンコーディング」、「クレーム」、「JWT クレームセット」を使用します。