Skip to content

OAuth 2.0 Token Exchange

Internet Engineering Task Force (IETF) M. Jones\ Request for Comments: 8693 A. Nadalin\ Category: Standards Track Microsoft\ ISSN: 2070-1721 B. Campbell, Ed.\ Ping Identity\ J. Bradley\ Yubico\ C. Mortimore\ Visa\ January 2020

Abstract

本仕様は、HTTP および JSON ベースの Security Token Service (STS) のためのプロトコルを定義する。具体的には、OAuth 2.0 Authorization Server からセキュリティトークンを要求し取得する方法を定義し、なりすまし（impersonation）および委任（delegation）を用いるセキュリティトークンも対象に含める。

Status of This Memo

これは Internet Standards Track 文書である。

本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を表し、公開レビューを受け、Internet Engineering Steering Group (IESG) により公開承認されている。Internet Standards に関する追加情報は RFC 7841 の Section 2 にある。

本文書の最新状況、正誤表（errata）、およびフィードバック提供方法については、以下から入手できる。\ https://www.rfc-editor.org/info/rfc8693

Copyright (c) 2020 IETF Trust および本文書の著者として特定された者。All rights reserved.

本文書は、本文書の公開日時点で有効な、IETF Trust の IETF Documents に関する法的規定\ (https://trustee.ietf.org/license-info) の対象となる。これらの文書には、本仕様に関する権利と制約が記載されているため、注意深く確認すること。本文書から抽出された Code Components には、Trust Legal Provisions の Section 4.e で述べられている Simplified BSD License の文言を含めなければならず、また Simplified BSD License に記載のとおり無保証で提供される。

Table of Contents

1. Introduction

セキュリティトークンとは、異種環境やセキュリティドメインをまたいで、アイデンティティ情報およびセキュリティ情報を共有することを容易にする情報の集合である。セキュリティトークンの例として、JSON Web Tokens (JWTs) [JWT] や Security Assertion Markup Language (SAML) 2.0 アサーション [OASIS.saml-core-2.0-os] がある。セキュリティトークンは、通常、完全性を確保するために署名され、場合によっては機密性を確保するために暗号化もされる。セキュリティトークンは、[RFC7521] のようにアサーションとして説明されることもある。

Security Token Service (STS) は、提示されたセキュリティトークンを検証し、その応答として新しいセキュリティトークンを発行できるサービスであり、これによりクライアントは、異種環境やセキュリティドメインをまたいだリソースに対して適切なアクセス資格情報を取得できる。Web Service のクライアントは、トークン交換のために STS とやり取りするプロトコルとして WS-Trust [WS-Trust] を用いてきた。WS-Trust は XML と SOAP を利用するが、近年の Web 開発では RESTful (Representational State Transfer) パターンと JSON へと移行する傾向がある。The OAuth 2.0 Authorization Framework [RFC6749] および OAuth 2.0 Bearer Tokens [RFC6750] は、HTTP および RESTful リソースへのサードパーティアプリケーションのアクセスを認可するための一般的な標準として台頭してきた。従来の OAuth 2.0 のやり取りでは、Resource Owner の認可を何らかの形で表したものを Access Token と交換するが、これは実運用において非常に有用なパターンであることが実証されている。しかし、この入出力は制約がやや強く、セキュリティトークン交換フレームワークを十分に収容するには不十分である。

本仕様は、STS の役割を担う Authorization Server からセキュリティトークンを要求し取得できるようにする OAuth 2.0 拡張プロトコルを定義する。OAuth 2.0 と同様、本仕様はクライアント開発者の容易さに重点を置き、現代の開発環境でほぼ普遍的に利用できる HTTP クライアントと JSON パーサのみを要件とする。本仕様で定義する STS プロトコル自体は RESTful ではない（STS は REST 的アプローチに特に向いていない）が、RESTful システムに慣れた開発者にとって馴染み深いはずの通信パターンとデータ形式を利用する。

本仕様は、トークン交換リクエストのための新しい grant_type と、token endpoint に対するそのリクエストに固有のパラメータを定義する。トークン交換レスポンスは、token endpoint から返される通常の OAuth 2.0 レスポンスであり、加えてここで定義するいくつかの追加パラメータによってクライアントに情報を提供する。

トークンを交換するリクエストを行う主体は、トークン交換のやり取りの文脈では client とみなされる。ただし、これにより、本仕様の利用が伝統的な OAuth clients に限定されるわけではない。OAuth resource server は、保護されたリソースリクエストで受け取った Access Token を、Backend service を呼び出す際に含めるのに適した新しいトークンへと交換するため、トークン交換中に client の役割を担うことがある。新しいトークンは、下流サービス向けにより狭い scope を持つ Access Token かもしれないし、まったく異なる種類のトークンである可能性もある。

本仕様の適用範囲は、OAuth 2.0 を用いた STS 形式のトークン交換について、基本的なリクエスト／レスポンスプロトコルを定義することに限定される。委任の意味を表現できるいくつかの新しい JWT claims は定義するが、トークンそのもの（Authorization Server に提示されるトークンおよび client が取得するトークン）の具体的な構文、意味、セキュリティ特性は明確に適用範囲外であり、実装が配備される信頼モデルに関する要件も課さない。追加プロファイルでは、関係者や信頼の具体的性質（トークンの署名や暗号化が必要か、proof-of-possession 形式のトークンが要求／発行されるか等）について、より詳細な要件を提示できる。しかし、そのような詳細は多くの場合、個別の配備の要件に基づくポリシー判断であり、それに応じて設定または実装される。

取得されたセキュリティトークンはさまざまな文脈で利用され得るが、その詳細も本仕様の適用範囲外である。

1.1. Delegation vs. Impersonation Semantics

STS の一般的なユースケースの 1 つ（前節で触れたとおり）は、resource server A が、リクエスト元ユーザー B のために Backend service C を呼び出せるようにすることである。ローカルのサイトポリシーと認可基盤によっては、A が自身の資格情報で C にアクセスしつつ、A が B を代行していることを何らかの形で注釈する（「delegation」）ことが望ましい場合もあれば、A が C に対する限定的なアクセス資格情報を付与されつつ、引き続き B を認可された主体として識別する（「impersonation」）ことが望ましい場合もある。delegation と impersonation は、複数参加者が関与する他のシナリオでも有用な概念である。

主体 A が主体 B を impersonation する場合、A は、ある定義された権利コンテキスト内で B が持つ権利をすべて与えられ、そのコンテキストでは B と区別がつかない。したがって、主体 A が主体 B を impersonation しているとき、そのようなトークンを受け取る任意の主体から見れば、実際に相手をしているのは B である。アイデンティティシステムの一部の構成要素が impersonation が行われていることを把握している可能性はあるが、それは要件ではない。実質的には、A が B を impersonation しているとき、A はトークンで認可された権利の範囲内において B である。A が B を impersonation できる能力は、トークン内容や帯域外の仕組みにより、範囲または時間で制限されたり、1 回限りの使用制限が付けられたりし得る。

delegation の意味は impersonation の意味とは異なるが、両者は密接に関連している。delegation の意味では、主体 A は B とは別個の自身のアイデンティティを保持し、B がその権利の一部を A に委任したとしても、行為は B を代表する A によって行われることが明示的に理解される。ある意味で、A は B の代理人である。

delegation と impersonation は、あらゆる状況を包含するものではない。例えば主体が自身のために直接行動している場合、delegation も impersonation も関係しない。しかし、これらはトークン交換でより一般的に用いられる意味であり、そのため本仕様ではより直接的に扱う。

delegation の意味は通常、トークンの主たる subject の情報に加え、その subject が権利の一部を委任した actor の情報を含めることでトークン内に表現される。そのようなトークンは、複数の subject に関する情報から構成されるため、複合トークン（composite token）と呼ばれることがある。通常、リクエストでは "subject_token" がトークンを要求している相手（誰のために要求しているか）のアイデンティティを表し、"actor_token" が、発行されるトークンのアクセス権が委任される相手のアイデンティティを表す。Authorization Server が発行する複合トークンには、両者に関する情報が含まれる。複合トークンを発行するかどうか、またいつ発行するかは、Authorization Server の裁量および適用されるポリシー／設定次第である。

複合トークンの表現方法や、そもそも発行されるかどうかは、実装の詳細およびトークンの種類に依存する。JWT ではない複合トークンの表現は本仕様の適用範囲外である。ただし、"actor_token" リクエストパラメータは、望ましい actor の情報を提供する手段を提供し、JWT の "act" claim は委任の連鎖を表現する手段を提供する。

1.2. Requirements Notation and Conventions

本文書中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL" というキーワードは、BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈される。ただし、それらがすべて大文字で現れる場合に限る。

1.3. Terminology

本仕様では、OAuth 2.0 [RFC6749] で定義されている "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", "token response" という用語と、JSON Web Token (JWT) [JWT] で定義されている "Base64url Encoding", "Claim", "JWT Claims Set" という用語を用いる。

2. Token Exchange Request and Response

2.1. Request

client は、[RFC6749] の Section 4.5 で定義される拡張 grant_type の仕組みを用いて、Authorization Server の token endpoint に token request を送ることでセキュリティトークンを要求する。

Authorization Server に対する client 認証は、OAuth 2.0 が提供する通常の仕組みを用いて行う。[RFC6749] の Section 2.3.1 はパスワードベースの client 認証を定義しているが、client 認証は拡張可能であり、他の仕組みも可能である。例えば [RFC7523] は bearer JSON Web Tokens (JWTs) [JWT] を用いた client 認証を定義している。client 認証としてどの方式をサポートするか、また未認証または未特定の client を許可するかどうかは、配備上の判断であり、Authorization Server の裁量による。client 認証を省略すると、漏えい・奪取されたトークンが、STS を介して別のトークンへと誰にでも悪用され得る点に注意すること。したがって、client 認証により、STS は、どの主体が他の主体を impersonation できるか、または他の主体から delegation を受け取れるかについて、追加の認可チェックを行える。

client は、HTTP の "POST" メソッドで、拡張 grant_type を用いたトークン交換リクエストを token endpoint に送る。以下のパラメータは、[RFC6749] の Appendix B で説明されているとおり、UTF-8 の文字エンコーディングで "application/x-www-form-urlencoded" 形式を用いて、HTTP リクエストの entity-body に含める。

  • grant_type\ REQUIRED。"urn:ietf:params:oauth:grant-type:token-exchange" という値は、トークン交換を実行していることを示す。

  • resource\ OPTIONAL。client が要求したセキュリティトークンを使用する意図がある、対象サービスまたはリソースを示す URI。これにより Authorization Server は、発行するトークンの種類や内容を決めたり、暗号化すべきかどうか、暗号化するならどのように行うかを決めたりするなど、対象に応じて適切なポリシーを適用できる。多くの場合、client は自身がやり取りするシステムの論理的な構成を把握しておらず、トークンを使用する予定のサービスの URI だけを知っている。"resource" パラメータにより、client は、発行されたトークンを使用する場所を、通常は https URL として、当該リソースにアクセスするのに用いるのと同じ形式で token exchange request に含めて、Authorization Server に示せる。Authorization Server は通常、resource URI の値から適切なポリシーに対応付ける能力を持つ。"resource" パラメータの値は、[RFC3986] の Section 4.3 で規定される絶対 URI でなければならず、query 部分を含んでもよいが、fragment 部分を含んではならない。複数の "resource" パラメータを使用して、発行されるトークンが列挙した複数リソースで使われる意図であることを示してもよい。[OAUTH-RESOURCE] に "resource" パラメータの背景と利用方法に関する追加情報がある。

  • audience\ OPTIONAL。client が要求したセキュリティトークンを使用する意図がある、対象サービスの論理名。これは "resource" パラメータと似た目的を果たすが、client が対象サービスの論理名を提供する点が異なる。その名前を解釈するには、client と Authorization Server の双方が理解できる値であることが必要である。OAuth client identifier、SAML entity identifier [OASIS.saml-core-2.0-os]、OpenID Connect Issuer Identifier [OpenID.Core] は、"audience" パラメータ値として用いられ得るものの例である。ただし、特定の Authorization Server で用いる "audience" 値は、その Server 内で一意でなければならず、意図した種類の値として正しく解釈されることを保証する必要がある。複数の "audience" パラメータを使用して、発行されるトークンが列挙した複数 audience で使われる意図であることを示してもよい。"audience" と "resource" は併用して、論理名と resource URI を混在させた複数の対象サービスを示してもよい。

  • scope\ OPTIONAL。[RFC6749] の Section 3.3 で定義される、空白区切りの大文字小文字を区別する文字列のリスト。これにより client は、トークンを使用するサービスまたはリソースの文脈で、要求するセキュリティトークンの望ましい scope を指定できる。scope の値とそれに対応する意味はサービス固有であり、関連するサービス文書で説明されることが想定される。

  • requested_token_type\ OPTIONAL。要求するセキュリティトークンの種類を示す識別子（Section 3 を参照）。要求する種類が指定されない場合、発行されるトークン種類は Authorization Server の裁量となり、"resource" または "audience" パラメータが示すサービス／リソースの要件に関する知識によって決まることがある。

  • subject_token\ REQUIRED。リクエストが誰のために行われているかを表すセキュリティトークン。通常、このトークンの subject が、リクエストに対する応答で発行されるセキュリティトークンの subject になる。

  • subject_token_type\ REQUIRED。"subject_token" パラメータに含まれるセキュリティトークンの種類を示す識別子（Section 3 を参照）。

  • actor_token\ OPTIONAL。行為主体（acting party）のアイデンティティを表すセキュリティトークン。通常、これは、要求されたセキュリティトークンの使用が許可され、subject のために行動する主体である。

  • actor_token_type\ "actor_token" パラメータに含まれるセキュリティトークンの種類を示す識別子（Section 3 を参照）。これは、リクエストに "actor_token" パラメータが存在する場合に REQUIRED だが、それ以外の場合は含めてはならない。

リクエストを処理するにあたり、Authorization Server は、指定されたトークン種類に対して適切な検証手続きを実行しなければならない。また actor_token が存在する場合は、その指定されたトークン種類に対しても適切な検証手続きを実行しなければならない。妥当性基準や特定トークンの詳細は本書の適用範囲外であり、各トークン種類およびその内容に固有である。

トークン種類に固有の 1 回限り使用などの意味がない限り、トークン交換を実行する行為は subject_token や actor_token の有効性に影響しない。さらに、交換は 1 回限りのイベントであり、入出力トークン間に強い結び付きを作らないため（例えば）出力トークンの有効期限が入力トークンの有効期限の影響を受けることはあり得るが、入力トークンの更新や延長が出力トークンの特性に反映されることは想定されない。トークン失効（revocation）のイベントを伝播することが適切または望ましい場合もある。しかし、それは STS プロトコルの一般的な性質ではなく、特定の実装、トークン種類、または配備に固有となる。

2.1.1. Relationship between Resource, Audience, and Scope

トークンを要求する際、client は "audience" と "resource" パラメータにより、そのトークンを使用する意図がある対象サービスを示せる。また "scope" パラメータにより、要求するトークンの望ましい scope を示せる。このようなリクエストの意味は、client が、要求した scope を持ち、かつ要求したすべての対象サービスで使用できるトークンを求めているということである。実質的に、トークンが要求するアクセス権は、すべての対象サービスにおけるすべての scope のデカルト積になる。

Authorization Server は、いかなるトークン要求も満たせない（あるいは満たす意思がない）場合があるが、非常に広範なアクセス権を求めるほど、満たせないリクエストになる可能性は大幅に高まる。そのため、配備におけるシステム間関係について特段の知識がない場合、client は、要求するアクセスの広さ、特に対象サービス数について慎重であるべきである。Authorization Server は、Section 2.2.2 で定義される "invalid_target" エラーコードを用いて、client が同時に多すぎる対象サービスへのアクセスを要求したことを通知できる。

2.2. Response

Authorization Server は、[RFC6749] の Section 5 で規定されるとおり、token endpoint からの通常の OAuth 2.0 レスポンスでトークン交換リクエストに応答する。追加の詳細と説明を以下の小節で示す。

2.2.1. Successful Response

リクエストが妥当であり、Authorization Server のポリシーおよびその他すべての基準を満たす場合、成功した token response は、HTTP レスポンスの entity-body に、以下のパラメータを追加して構成される。レスポンスは [RFC8259] に従い "application/json" メディアタイプを用い、HTTP 200 ステータスコードとする。パラメータは、各パラメータをトップレベルに追加して JSON 構造へ直列化する。パラメータ名と文字列値は JSON 文字列として含める。数値は JSON 数値として含める。パラメータの順序は重要ではなく、変わり得る。

  • access_token\ REQUIRED。トークン交換リクエストに対する応答として Authorization Server が発行したセキュリティトークン。[RFC6749] の Section 5.1 の "access_token" パラメータを、要求されたトークンを運ぶためにここで用いる。これにより、トークン交換プロトコルは token endpoint 向けに定義された既存の OAuth 2.0 のリクエスト／レスポンス構成要素を利用できる。"access_token" という識別子は歴史的理由で用いられており、発行されたトークンは OAuth access token である必要はない。

  • issued_token_type\ REQUIRED。発行されたセキュリティトークンの表現を示す識別子（Section 3 を参照）。

  • token_type\ REQUIRED。[RFC6749] の Section 7.1 で規定されるとおり、発行された access token の使用方法を指定する大文字小文字を区別しない値。これは、保護されたリソースにアクセスするために access token をどのように利用すべきかを client に提供する。例えば [RFC6750] で規定される "Bearer" 値は、発行されたセキュリティトークンが bearer token であり、client はトークン内容以外の追加の資格証明を示すことなく、そのまま提示できることを示す。このパラメータの意味は、発行されたセキュリティトークンの表現を宣言する "issued_token_type" パラメータの意味とは異なる点に注意すること。"token type" という用語は通常、セキュリティトークンの構造的／構文的表現を意味するため、本仕様中のすべての "*_token_type" パラメータではその意味で用いられている。発行されたトークンが access token ではない、または access token として利用できない場合、"token_type" 値として "N_A" を用い、その文脈では OAuth 2.0 の "token_type" 識別子が適用できないことを示す。

  • expires_in\ RECOMMENDED。Authorization Server が発行したトークンの有効期間（秒）。多くの場合、client はトークン内容を検査する意図や能力を持たないため、このパラメータは、トークン種類に依存しない形で、トークンがどれくらい有効と見込めるかの一貫した指標を提供する。例えば 1800 は、レスポンス生成時刻から 30 分後にトークンが期限切れになることを示す。

  • scope\ 発行されたセキュリティトークンの scope が、client が要求した scope と同一であれば OPTIONAL。そうでなければ REQUIRED。

  • refresh_token\ OPTIONAL。通常、交換が、一時的な資格情報（subject_token）を、別文脈で利用するための別の一時的な資格情報（発行トークン）へ交換するものである場合、Refresh Token は発行されない。Refresh Token は、トークン交換の client が、元の資格情報がもはや有効でない場合でもリソースへアクセスできる能力を必要とする場合に発行され得る（例: user-not-present、または client と End-User のアクティブセッションが存在しない offline シナリオ）。本仕様のプロファイルや配備は、"urn:ietf:params:oauth:grant-type:token-exchange" の grant_type リクエストに対して、どの条件で client が Refresh Token を期待すべきかを明確に文書化すべきである。

2.2.2. Error Response

リクエスト自体が妥当でない場合、または "subject_token" もしくは "actor_token" が何らかの理由で無効である場合、あるいはポリシー上受け入れられない場合、Authorization Server は [RFC6749] の Section 5.2 で規定されるとおり error response を構築しなければならない。"error" パラメータの値は "invalid_request" エラーコードでなければならない。

Authorization Server が、"resource" または "audience" パラメータが示すいずれかの対象サービスに対してトークンを発行する意思がない、または発行できない場合、error response では "invalid_target" エラーコードを用いるべきである。

Authorization Server は、[RFC6749] の Section 5.2 で述べられている "error_description" を用いて、エラー理由に関する追加情報を含めてもよい。

その他のエラーコードも、必要に応じて使用してよい。

2.3. Example Token Exchange

以下の例は、OAuth resource server が交換中に client の役割を担う、仮想的なトークン交換を示す。resource server は、保護されたリソースリクエストで受け取った Access Token を、Backend service を呼び出すために使用する新しいトークンと交換する（例中の余分な改行とインデントは表示のためのみ）。

Figure 1 は、[RFC6750] の Section 2.1 に従い、resource server が Authorization ヘッダ内に OAuth access token を含む保護されたリソースリクエストを受け取る様子を示す。

GET /resource HTTP/1.1
Host: frontend.example.com
Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC

Figure 1: Protected Resource Request

Figure 2 では、resource server がトークン交換のために client の役割を担い、Figure 1 のリクエストから得た Access Token を、Section 2.1 で規定されるリクエストを用いて Authorization Server に送る。"subject_token" パラメータの値は Access Token を運び、"subject_token_type" パラメータの値はそれが OAuth 2.0 access token であることを示す。resource server は client の役割で行動し、HTTP Basic 認証スキームを用いて identifier と secret により Authorization Server へ認証する。"resource" パラメータは、発行されたトークンが使用される Backend service の場所 https://backend.example.com/api を示す。

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fbackend.example.com%2Fapi
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subject_token_type=
 urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

Figure 2: Token Exchange Request

Authorization Server は client 資格情報と、トークン交換リクエストに提示された "subject_token" を検証する。"resource" パラメータから、Authorization Server はリクエストに適用すべき適切なポリシーを決定でき、https://backend.example.com での利用に適したトークンを発行する。Figure 3 に示すレスポンスの "access_token" パラメータには新しいトークンが含まれており、これは bearer の OAuth access token で、1 分間有効である。トークンはたまたま JWT であるが、その構造と形式は client からは不透明であるため、"issued_token_type" は access token であることしか示していない。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
   dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
   4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
   N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
   f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
   y5-kdXjwhw",
 "issued_token_type":
     "urn:ietf:params:oauth:token-type:access_token",
 "token_type":"Bearer",
 "expires_in":60
}

Figure 3: Token Exchange Response

resource server は、その後、Figure 4 に示すように、新たに取得した Access Token を用いて Backend server へのリクエストを行える。

GET /api HTTP/1.1
Host: backend.example.com
Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
   iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2F
   zLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
   zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
   dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
   vmDCMy5-kdXjwhw

Figure 4: Backend Protected Resource Request

追加の例は Appendix A にある。

3. Token Type Identifiers

本仕様のいくつかのパラメータは、対象トークンを記述する値として識別子を利用する。具体的には、リクエストの "requested_token_type", "subject_token_type", "actor_token_type" と、レスポンスの "issued_token_type" メンバーである。トークン種類の識別子は URI である。トークン交換は、他の主体が発行したトークンと、当該 Authorization Server が発行したトークンの両方に対応できる。前者の場合、トークン種類識別子は（JWT や SAML 2.0 などの）構文を示し、Authorization Server がそれを解析できるようにする。後者の場合、当該 Authorization Server がそれを何のために発行したか（例: "access_token" や "refresh_token"）を示す。

以下のトークン種類識別子を本仕様で定義する。その他の URI を、他のトークン種類を示すために使用してよい。

  • urn:ietf:params:oauth:token-type:access_token\ 当該 Authorization Server が発行した OAuth 2.0 access token であることを示す。

  • urn:ietf:params:oauth:token-type:refresh_token\ 当該 Authorization Server が発行した OAuth 2.0 Refresh Token であることを示す。

  • urn:ietf:params:oauth:token-type:id_token\ [OpenID.Core] の Section 2 で定義される ID Token であることを示す。

  • urn:ietf:params:oauth:token-type:saml1\ base64url エンコードされた SAML 1.1 [OASIS.saml-core-1.1] アサーションであることを示す。

  • urn:ietf:params:oauth:token-type:saml2\ base64url エンコードされた SAML 2.0 [OASIS.saml-core-2.0-os] アサーションであることを示す。

[JWT] の Section 9 で定義される値 "urn:ietf:params:oauth:token-type:jwt" は、トークンが JWT であることを示す。

access token と JWT の区別は微妙である。access token は委任された認可判断を表す一方、JWT はトークン形式である。access token は JWT 形式で表現され得るが、必ずしもそうである必要はない。また、JWT が access token である場合もあり得るが、すべての JWT が access token であるわけではない。本仕様の意図は、"urn:ietf:params:oauth:token-type:access_token" を、当該 Authorization Server が発行した典型的な OAuth access token であり、client に対して不透明で、同じ Authorization Server から取得する他の access token と同様の方法で利用可能であることを示す指標として扱うことである（JWT である場合もあり得るが、client はその事実を把握していないし、把握する必要もない）。一方で、"urn:ietf:params:oauth:token-type:jwt" は、JWT を要求または送信していることを特に示すために用いる（例えば、JWT を認可 grant として用い、[RFC7523] で実現されるように、別の Authorization Server から access token を取得するクロスドメインのユースケースなど）。

トークンがバイナリ性を持つ場合、HTTP と OAuth での利用に適した base64 などのエンコーディングの意味と関連付けられた URI を用いて、それを伝達する必要がある点に注意すること。

4. JSON Web Token Claims and Introspection Response Parameters

トークン内で delegation を表現する仕組み、および delegation や impersonation を行う認可を表現する仕組みを定義しておくことは有用である。トークン交換プロトコルは任意の種類のトークンで利用できるが、本節では、JWT 向け、および OAuth 2.0 Token Introspection [RFC7662] レスポンス向けに、これらの意味を表現する claims を定義する。他の種類のトークンに対する類似定義も可能だが、本仕様の適用範囲外である。

なお、例や説明で使用されるが本節で新たに定義しない claims（"iss", "sub", "exp" など）は [JWT] で定義される。

4.1. "act" (Actor) Claim

"act"（actor）claim は、JWT 内で delegation が発生したことを表し、権限が委任された行為主体（acting party）を特定する手段を提供する。"act" claim の値は JSON object であり、その JSON object のメンバーは actor を特定する claims である。"act" claim を構成する claims は actor を識別し、場合によっては actor に関する追加情報を提供する。例えば、actor を一意に特定するには "iss" と "sub" の 2 つの claims の組み合わせが必要となる場合がある。

ただし "act" claim 内の claims は actor のアイデンティティのみに関係し、トップレベルの claims と同様の形で、包含する JWT の妥当性に関係するわけではない。したがって、"exp", "nbf", "aud" のような非アイデンティティ claims は "act" claim 内で用いても意味がなく、そのため使用しない。

Figure 5 は、JWT Claims Set 内の "act"（actor）claim を示す。トークン自体の claims は user@example.com に関するものであり、"act" claim は admin@example.com が現在の actor であることを示す。

{
  "aud": "https://consumer.example.com",
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "nbf": 1443904077,
  "sub": "user@example.com",
  "act": {
    "sub": "admin@example.com"
  }
}

Figure 5: Actor Claim

委任の連鎖は、ある "act" claim の中に別の "act" claim をネストさせることで表現できる。最外の "act" claim は現在の actor を表し、ネストされた "act" claims は過去の actor を表す。最も古い actor は最も深くネストされる。ネストされた "act" claims は、最初のリクエストと subject が、現在の actor に到達するまでに経た委任ステップを結び付ける履歴トレイルとして機能する。この意味で、現在の actor は、全体の認可／委任の履歴を含むものとみなされ、ここで述べたネスト構造へ自然に繋がる。

アクセス制御ポリシー適用のために、トークンの利用者は、トークンのトップレベルの claims と、"act" claim が特定する現在の actor のみを考慮しなければならない。ネストされた "act" claims が特定する過去の actor は参考情報に過ぎず、アクセス制御判断に考慮してはならない。

Figure 6 の例は、JWT Claims Set 内のネストされた "act"（actor）claims を示す。トークン自体の claims は user@example.com に関するものであり、"act" claim は、システム https://service16.example.com が現在の actor であり、https://service77.example.com が過去の actor であることを示す。このようなトークンは、service16 が service77 からの呼び出しでトークンを受け取り、それを service26 を呼び出すのに適したトークンへ交換し、Authorization Server が新たに発行したトークンにその状況を記録した結果として生じ得る。

{
  "aud": "https://service26.example.com",
  "iss": "https://issuer.example.com",
  "exp": 1443904100,
  "nbf": 1443904000,
  "sub": "user@example.com",
  "act": {
    "sub": "https://service16.example.com",
    "act": {
      "sub": "https://service77.example.com"
    }
  }
}

Figure 6: Nested Actor Claim

OAuth token introspection response のトップレベルメンバーとして "act" を含める場合、同名の claim と同じ意味と形式を持つ。

4.2. "scope" (Scopes) Claim

"scope" claim の値は JSON 文字列であり、トークンに関連付く scopes の空白区切りリストを含む。形式は [RFC6749] の Section 3.3 で説明されているとおりである。

Figure 7 は JWT Claims Set 内の "scope" claim を示す。

{
  "aud": "https://consumer.example.com",
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "nbf": 1443904077,
  "sub": "dgaf4mvfs75Fci_FL3heQA",
  "scope": "email profile phone address"
}

Figure 7: Scopes Claim

OAuth 2.0 Token Introspection [RFC7662] は、トークンに関連付く scopes を伝達するための "scope" パラメータをすでに定義している。

4.3. "client_id" (Client Identifier) Claim

"client_id" claim は、トークンを要求した OAuth 2.0 [RFC6749] client の client identifier を運ぶ。

Figure 8 の例は、JWT Claims Set 内の "client_id" claim を示し、識別子が "s6BhdRkqt3" の OAuth 2.0 client であることを示す。

{
  "aud": "https://consumer.example.com",
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "sub": "user@example.com",
  "client_id": "s6BhdRkqt3"
}

Figure 8: Client Identifier Claim

OAuth 2.0 Token Introspection [RFC7662] は、トークンを要求した OAuth 2.0 client の client identifier として "client_id" パラメータをすでに定義している。

4.4. "may_act" (Authorized Actor) Claim

"may_act" claim は、ある主体が actor になり、別の主体のために行動することを許可されている、という主張を表す。例えば、トークン交換リクエストで "subject_token" が token endpoint に提示された場合、subject token に含まれる "may_act" claim を、Authorization Server が、client（または "actor_token" で特定される主体）が要求された delegation または impersonation に関与することを許可されているかどうかを判断するために利用できる。claim の値は JSON object であり、その JSON object のメンバーは、当該 claim を含む JWT が特定する主体のために行動する資格があると主張される主体を特定する claims である。"may_act" claim を構成する claims は、その許可された actor を識別し、場合によっては追加情報を提供する。例えば、許可された actor を一意に特定するには "iss" と "sub" の 2 つの claims の組み合わせが必要となる場合があり、また "email" claim が追加の有用情報を提供するために使われる場合がある。

ただし "may_act" claim 内の claims はその主体のアイデンティティのみに関係し、トップレベルの claims と同様の形で、包含する JWT の妥当性に関係するわけではない。したがって、"exp", "nbf", "aud" などの claims は "may_act" claim 内で用いても意味がなく、そのため使用しない。

Figure 9 は JWT Claims Set 内の "may_act" claim を示す。トークン自体の claims は user@example.com に関するものであり、"may_act" claim は admin@example.com が user@example.com のために行動することを許可されていることを示す。

{
  "aud": "https://consumer.example.com",
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "nbf": 1443904077,
  "sub": "user@example.com",
  "may_act": {
    "sub": "admin@example.com"
  }
}

Figure 9: Authorized Actor Claim

OAuth token introspection response のトップレベルメンバーとして "may_act" を含める場合、同名の claim と同じ意味と形式を持つ。

5. Security Considerations

[RFC6749] の Section 10（The OAuth 2.0 Authorization Framework の Security Considerations）にあるガイダンスの多くは、ここでも適用できる。さらに、[RFC6819] は OAuth の追加のセキュリティ考慮事項を提供し、[OAUTH-SECURITY] は、OAuth 2.0 公開以降に現れた配備経験と新たな脅威に基づき、セキュリティガイダンスを更新している。

[JWT] で議論されている通常のセキュリティ問題、特に URI 比較や未認識値の扱いに関する論点も、ここに適用される。

加えて、delegation と impersonation は固有のセキュリティ問題を導入する。ある主体が別の主体の権利を委任される状況では、常に濫用の可能性が懸念となる。このような濫用の可能性を緩和するため、（トークンの有効期間を短くするなどの他の典型的制約に加え）"scope" claim の利用が推奨される。これは、委任された権利が行使できる文脈を制限するためである。

6. Privacy Considerations

ここで述べる機能の文脈で用いられるトークンにはプライバシー上機微な情報が含まれ得る。そのような情報が意図しない主体に開示されるのを防ぐため、トークンは Transport Layer Security (TLS) のような暗号化チャネル上でのみ送信しなければならない。client に対して特定の情報が開示されるのを防ぐことが望ましい場合、トークンは意図した受領者向けに暗号化しなければならない。配備は、必要最小限のデータ量を決定し、発行されるトークンにはそのような情報のみを含めるべきである。場合によっては、データ最小化の一環として、匿名または仮名のユーザーのみを表現することもあり得る。

7. IANA Considerations

7.1. OAuth URI Registration

IANA は "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth URI" サブレジストリに、以下の値を登録した。"OAuth URI" サブレジストリは [RFC6755] により確立された。

  • URN: urn:ietf:params:oauth:grant-type:token-exchange
  • Common Name: Token exchange grant type for OAuth 2.0
  • Change Controller: IESG

  • Specification Document: Section 2.1 of RFC 8693

  • URN: urn:ietf:params:oauth:token-type:access_token

  • Common Name: Token type URI for an OAuth 2.0 access token
  • Change Controller: IESG

  • Specification Document: Section 3 of RFC 8693

  • URN: urn:ietf:params:oauth:token-type:refresh_token

  • Common Name: Token type URI for an OAuth 2.0 refresh token
  • Change Controller: IESG

  • Specification Document: Section 3 of RFC 8693

  • URN: urn:ietf:params:oauth:token-type:id_token

  • Common Name: Token type URI for an ID Token
  • Change Controller: IESG

  • Specification Document: Section 3 of RFC 8693

  • URN: urn:ietf:params:oauth:token-type:saml1

  • Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion
  • Change Controller: IESG

  • Specification Document: Section 3 of RFC 8693

  • URN: urn:ietf:params:oauth:token-type:saml2

  • Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion
  • Change Controller: IESG
  • Specification Document: Section 3 of RFC 8693

7.2. OAuth Parameters Registration

IANA は "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Parameters" サブレジストリに、以下の値を登録した。"OAuth Parameters" サブレジストリは [RFC6749] により確立された。

  • Parameter name: audience
  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: requested_token_type

  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: subject_token

  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: subject_token_type

  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: actor_token

  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: actor_token_type

  • Parameter usage location: token request
  • Change controller: IESG

  • Specification document(s): Section 2.1 of RFC 8693

  • Parameter name: issued_token_type

  • Parameter usage location: token response
  • Change controller: IESG
  • Specification document(s): Section 2.2.1 of RFC 8693

7.3. OAuth Access Token Type Registration

IANA は "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Access Token Types" サブレジストリに、以下の access token type を登録した。"OAuth Access Token Types" サブレジストリは [RFC6749] により確立された。

  • Type name: N_A
  • Additional Token Endpoint Response Parameters: none
  • HTTP Authentication Scheme(s): none
  • Change controller: IESG
  • Specification document(s): Section 2.2.1 of RFC 8693

7.4. JSON Web Token Claims Registration

IANA は "JSON Web Token (JWT)" レジストリ [IANA.JWT] の "JSON Web Token Claims" サブレジストリに、以下の Claims を登録した。"JSON Web Token Claims" サブレジストリは [JWT] により確立された。

  • Claim Name: act
  • Claim Description: Actor
  • Change Controller: IESG

  • Specification Document(s): Section 4.1 of RFC 8693

  • Claim Name: scope

  • Claim Description: Scope Values
  • Change Controller: IESG

  • Specification Document(s): Section 4.2 of RFC 8693

  • Claim Name: client_id

  • Claim Description: Client Identifier
  • Change Controller: IESG

  • Specification Document(s): Section 4.3 of RFC 8693

  • Claim Name: may_act

  • Claim Description: Authorized Actor - the party that is authorized to become the actor
  • Change Controller: IESG
  • Specification Document(s): Section 4.4 of RFC 8693

7.5. OAuth Token Introspection Response Registration

IANA は "OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Token Introspection Response" レジストリに、以下の値を登録した。"OAuth Token Introspection Response" レジストリは [RFC7662] により確立された。

  • Name: act
  • Description: Actor
  • Change Controller: IESG

  • Specification Document(s): Section 4.1 of RFC 8693

  • Name: may_act

  • Description: Authorized Actor - the party that is authorized to become the actor
  • Change Controller: IESG
  • Specification Document(s): Section 4.4 of RFC 8693

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Additional Token Exchange Examples

以下の節では、それぞれ impersonation と delegation を例示する 2 つのトークン交換例を示す（例中の余分な改行とインデントは表示のためのみ）。

A.1. Impersonation Token Exchange Example

A.1.1. Token Exchange Request

次の token exchange request では、client は impersonation の意味を持つトークンを要求している（"subject_token" のみで "actor_token" がない場合、delegation は不可能である）。client は Authorization Server に対し、論理名 "urn:example:cooperation-context" を持つ対象サービスで使用するためのトークンが必要であることを伝える。

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=urn%3Aexample%3Acooperation-context
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
  zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
  uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
  3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
  0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
  hF64pbTtfjy4VXFVBDaQpKjn5JzAw
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

Figure 10: Token Exchange Request

A.1.2. Subject Token Claims

直前のリクエストにおける "subject_token" は JWT であり、デコードされた JWT Claims Set を以下に示す。JWT は特定の時間枠内で Authorization Server によって消費される意図がある。JWT の subject（"bdc@example.net"）は、新しいトークンがその behalf で要求されている主体である。

{
  "aud": "https://as.example.com",
  "iss": "https://original-issuer.example.net",
  "exp": 1441910600,
  "nbf": 1441909000,
  "sub": "bdc@example.net",
  "scope": "orders profile history"
}

Figure 11: Subject Token Claims

A.1.3. Token Exchange Response

以下に示すトークン交換レスポンスの "access_token" パラメータには、client が要求した新しいトークンが含まれる。レスポンスの他のパラメータは、トークンが bearer の access token であり、1 時間で期限切れになることを示す。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
   6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
   eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
   mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
   uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
   nVKh85A",
 "issued_token_type":
   "urn:ietf:params:oauth:token-type:access_token",
 "token_type":"Bearer",
 "expires_in":3600
}

Figure 12: Token Exchange Response

A.1.4. Issued Token Claims

発行されたトークンのデコード済み JWT Claims Set を以下に示す。新しい JWT は Authorization Server により発行され、期限切れまでの任意の時点で、論理名 "urn:example:cooperation-context" で知られるシステム主体によって消費される意図がある。JWT の subject（"sub"）は、リクエストに用いたトークンの subject と同一であり、これは、client が当該トークンを用いることで、論理名 "urn:example:cooperation-context" のシステム主体に対して、その subject を impersonation できることを実質的に可能にする。

{
  "aud": "urn:example:cooperation-context",
  "iss": "https://as.example.com",
  "exp": 1441913610,
  "sub": "bdc@example.net",
  "scope": "orders profile history"
}

Figure 13: Issued Token Claims

A.2. Delegation Token Exchange Example

A.2.1. Token Exchange Request

次の token exchange request では、client はトークンを要求し、"subject_token" と "actor_token" の両方を提供する。client は Authorization Server に対し、論理名 "urn:example:cooperation-context" を持つ対象サービスで使用するためのトークンが必要であることを伝える。Authorization Server のポリシーにより、発行トークンは複合（composite）であることが求められている。

POST /as/token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=urn%3Aexample%3Acooperation-context
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
  zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
  uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
  WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
  pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
  xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
  vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
  XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
  ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
  oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

Figure 14: Token Exchange Request

A.2.2. Subject Token Claims

直前のリクエストにおける "subject_token" は JWT であり、デコードされた JWT Claims Set を以下に示す。この JWT は、特定の期限切れ時刻より前に Authorization Server によって消費される意図がある。JWT の subject（"user@example.net"）は、新しいトークンがその behalf で要求されている主体である。

{
  "aud": "https://as.example.com",
  "iss": "https://original-issuer.example.net",
  "exp": 1441910060,
  "scope": "status feed",
  "sub": "user@example.net",
  "may_act": {
    "sub": "admin@example.net"
  }
}

Figure 15: Subject Token Claims

A.2.3. Actor Token Claims

直前のリクエストにおける "actor_token" は JWT であり、デコードされた JWT Claims Set を以下に示す。この JWT もまた、特定の期限切れ時刻より前に Authorization Server によって消費される意図がある。JWT の subject（"admin@example.net"）は、要求されているセキュリティトークンを行使する actor である。

{
  "aud": "https://as.example.com",
  "iss": "https://original-issuer.example.net",
  "exp": 1441910060,
  "sub": "admin@example.net"
}

Figure 16: Actor Token Claims

A.2.4. Token Exchange Response

以下に示すトークン交換レスポンスの "access_token" パラメータには、client が要求した新しいトークンが含まれる。レスポンスの他のパラメータは、トークンが JWT であり 1 時間で期限切れになること、そして発行トークンが access token ではないため access token の種別は適用できないことを示す。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store

{
 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
   6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
   eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
   CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
   hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
   9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
 "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
 "token_type":"N_A",
 "expires_in":3600
}

Figure 17: Token Exchange Response

A.2.5. Issued Token Claims

発行されたトークンのデコード済み JWT Claims Set を以下に示す。新しい JWT は Authorization Server により発行され、期限切れまでの任意の時点で、論理名 "urn:example:cooperation-context" で知られるシステム主体によって消費される意図がある。JWT の subject（"sub"）は、リクエストに用いた "subject_token" の subject と同一である。JWT の actor（"act"）は、リクエストに用いた "actor_token" の subject と同一である。これは delegation を示し、"admin@example.net" が、"user@example.net" のために行動する権限を委任された現在の actor であることを特定する。

{
  "aud": "urn:example:cooperation-context",
  "iss": "https://as.example.com",
  "exp": 1441913610,
  "scope": "status feed",
  "sub": "user@example.net",
  "act": {
    "sub": "admin@example.net"
  }
}

Figure 18: Issued Token Claims

Acknowledgements

本仕様は OAuth Working Group 内で開発された。同 WG には、数十名の活発で献身的な参加者が含まれる。本仕様は、Hannes Tschofenig、Derek Atkins、Rifaat Shekh-Yusef の議長の下で作成され、Kathleen Moriarty、Stephen Farrell、Eric Rescorla、Roman Danyliw、Benjamin Kaduk が Security Area Directors を務めた。

以下の個人が、本仕様へのアイデア、フィードバック、文言作成に貢献した: Caleb Baker, Vittorio Bertocci, Mike Brown, Thomas Broyer, Roman Danyliw, William Denniss, Vladimir Dzhuvinov, Eric Fazendin, Phil Hunt, Benjamin Kaduk, Jason Keglovitz, Torsten Lodderstedt, Barry Leiba, Adam Lewis, James Manger, Nov Matake, Matt Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer, Adam Roach, Rifaat Shekh-Yusef, Scott Tomilson, Hannes Tschofenig.

Authors' Addresses

Michael B. Jones

Microsoft

Email: mbj@microsoft.com\ URI: https://self-issued.info/

Anthony Nadalin

Microsoft

Email: tonynad@microsoft.com

Brian Campbell (editor)

Ping Identity

Email: brian.d.campbell@gmail.com

John Bradley

Yubico

Email: ve7jtb@ve7jtb.com

Chuck Mortimore

Visa

Email: chuck.mortimore@visa.com