Microsoft ID プラットフォーム アクセス トークン
アクセス トークンにより、クライアントは保護された Web API を安全に呼び出すことができます。 Web API は、認証と認可を実行するためにアクセス トークンを使用します。
OAuth 仕様では、アクセス トークンは、設定された形式を持たない不透明型の文字列です。 ID プロバイダー (IDP) には、GUID を使用するものと、暗号化された BLOB を使用するものがあります。 アクセス トークンの形式は、トークンを受け入れる API の構成方法によって異なります。
Microsoft ID プラットフォームで開発者によって登録されるカスタム API では、v1.0 および v2.0 と呼ばれる 2 つの異なる形式の JSON Web Token (JWT) のいずれかを選択できます。 Microsoft Graph などの Microsoft が開発した API や Azure の API には、その他の専用トークンの形式があります。 これらの専用形式は、暗号化トークン、JWT、または検証を行わない特殊な JWT 類似トークンである可能性があります。
トークンの内容は特定の API のみを対象としているため、クライアントはアクセス トークンを不透明型の文字列として扱う必要があります。 検証とデバッグ "のみ" を目的として、開発者は jwt.ms などのサイトを使用して JWT をデコードできます。 Microsoft API に対して受信されるトークンは、常に JWT であるとは限らず、常にデコードできるわけではありません。
アクセス トークン内の内容の詳細については、クライアントは、アクセス トークンと共にクライアントに返されるトークン応答データを使用する必要があります。 クライアントがアクセス トークンを要求すると、Microsoft ID プラットフォームからは、アプリケーションで使用されるそのアクセス トークンに関する何らかのメタデータも返されます。 この情報には、アクセス トークンの有効期限や、それが有効なスコープが含まれます。 このデータを使用すると、アプリケーションはアクセス トークン自体を解析しなくても、そのアクセス トークンのインテリジェントなキャッシュを実行できます。
API でアクセス トークン内の要求を検証して使用する方法については、次のセクションをご覧ください。
注意
このページのすべてのドキュメントは、特に記載がある場合を除き、登録された API に対して発行されるトークンにのみ適用されます。 Microsoft が所有する API に対して発行されるトークンには適用されません。また、それらのトークンを使用して、Microsoft ID プラットフォームが、登録された API に対してトークンを発行する方法を検証することもできません。
トークンの形式
Microsoft ID プラットフォームで使用できるアクセス トークンには、v1.0 と v2.0 の 2 つのバージョンがあります。 これらのバージョンでは、トークン内の要求を決定し、Web API がトークンの内容を制御できるようにします。
Web API では、登録時に次のいずれかのバージョンが既定として選択されます。
Azure AD 専用アプリケーションの場合、v1.0。 次の例では、v1.0 トークンを示しています (このトークンの例では、公開前にキーがローテーションされ、個人情報が削除されているため、検証されません)。
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHdコンシューマー アカウントをサポートするアプリケーションの場合、v2.0。 次の例では、v2.0 トークンを示しています (このトークンの例では、公開前にキーがローテーションされ、個人情報が削除されているため、検証を行いません)。
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
アプリ マニフェストの accessTokenAcceptedVersion 設定に適切な値を指定することで、アプリケーションのバージョンを設定できます。 null および 1 の値では v1.0 トークンになり、2 の値では v2.0 トークンになります。
トークンの所有権
アクセス トークン要求には、トークンを要求するクライアントと、トークンを受け入れるリソース (Web API) の 2 つのパーティが関与します。 トークン内の aud 要求は、トークンが対象とするリソース (その "対象者") を示します。 クライアントはトークンを使用しますが、それを理解したり解析しようとしたりすることはできません。 リソースはトークンを受け入れます。
Microsoft ID プラットフォームでは、任意のバージョンのエンドポイントからの任意のトークン バージョンの発行がサポートされています。これらは関連性がありません。 accessTokenAcceptedVersion を 2 に設定すると、v1.0 エンドポイントを呼び出してそのリソースのトークンを取得するクライアントは、v2.0 アクセス トークンを受け取ることになります。
リソースは、aud 要求を使用するトークンを常に所有し、トークンの詳細を変更できる唯一のアプリケーションになります。
アクセス トークン内のクレーム
JWT は次の 3 つの部分に分かれています。
- ヘッダー - トークンの種類や署名方法に関する情報など、トークンの検証方法に関する情報が提供されます。
- ペイロード - サービスを呼び出そうとしているユーザーまたはアプリケーションに関する重要なデータがすべて含まれています。
- 署名 - トークンの検証に使用される原材料です。
各部分はピリオド (.) で区切られ、Base64 で個別にエンコードされます。
クレームは、そこに入力される値が存在する場合にのみ存在します。 アプリケーションは要求の存在に依存することはできません。 例として、pwd_exp (すべてのテナントでパスワードを期限切れにする必要があるわけではありません) や、family_name (名前のないアプリケーションに代わって、クライアント資格情報フローが使用されます) などがあります。 アクセス トークンの検証に使用されるクレームは常に存在します。
再利用のために、Microsoft ID プラットフォームを使ったトークンのセキュリティ保護に活用されるクレームもあります。 これらのクレームは公開されないものとして、記述で Opaque としてマークされます。 これらのクレームはトークンに表示される場合とされない場合があり、新しいものが予告なく追加される場合もあります。
ヘッダーのクレーム
| 要求 | Format | 説明 |
|---|---|---|
typ |
文字列 - 常に JWT |
トークンが JWT であることを示します。 |
alg |
String | トークンの署名に使用されたアルゴリズム (RS256 など) を示します。 |
kid |
String | このトークンの署名を検証するために使用できる公開キーの拇印を指定します。 v1.0 と v2.0 のどちらのアクセス トークンでも生成されます。 |
x5t |
String | kid と同様に機能します (使用方法も値も同じ)。 x5t は、互換性を目的として v1.0 アクセス トークンでのみ生成されるレガシ クレームです。 |
ペイロードのクレーム
| 要求 | Format | 説明 |
|---|---|---|
aud |
文字列、アプリケーション ID URI、または GUID | トークンの想定されている読者を識別します。 API でこの値を検証し、値が一致しない場合はトークンを拒否する必要があります。 v2.0 トークンでは、この値は常に API のクライアント ID です。 v1.0 トークンでは、これは、クライアント ID、または要求で使用されるリソース URI になります。 値は、クライアントがトークンを要求した方法によって異なります。 |
iss |
文字列、セキュリティ トークン サービス (STS) URI | トークンを作成して返した STS、およびユーザーが認証された Azure AD テナントを示します。 発行されたトークンが v2.0 トークンである場合 (ver 要求を参照)、URI は /v2.0 で終了します。 ユーザーが Microsoft アカウントを持つコンシューマー ユーザーであることを示す GUID は 9188040d-6c67-4c5b-b112-36a304b66dad です。 アプリケーションでは、要求の GUID 部分を使用して、アプリケーションにサインインできるテナントのセットを制限できます (該当する場合)。 |
idp |
文字列 (通常は STS URI) | トークンのサブジェクトを認証した ID プロバイダーを記録します。 この値は、発行者とテナントが異なるユーザー アカウント (ゲストなど) の場合を除いて、発行者クレームの値と同じです。 クレームが存在しない場合は、代わりに iss の値を使用できます。 個人用アカウントが組織のコンテキストで使用されている場合 (たとえば、個人用アカウントが Azure AD テナントに招待された場合)、idp 要求は 'live.com' または Microsoft アカウント テナント 9188040d-6c67-4c5b-b112-36a304b66dad を含む STS URI である可能性があります。 |
iat |
int、Unix タイムスタンプ | このトークンの認証がいつ行われたのかを示します。 |
nbf |
int、Unix タイムスタンプ | JWT を受け入れて処理することができない時間を指定します。 |
exp |
int、Unix タイムスタンプ | JWT を受け入れて処理することができない時間を指定します。 この日時より前でも、リソースがトークンを拒否する場合もありあす。 拒否は、認証の変更が必要な場合、またはトークンの失効が検出された場合に発生する可能性があります。 |
aio |
あいまいな文字列 | Azure AD がトークン再利用のためにデータの記録に使用する内部の要求。 リソースでこの要求を使用しないでください。 |
acr |
文字列、「0」 または 「1」、v1.0 トークンにのみ存在する |
"認証コンテキスト クラス" 要求の値 「0」 は、エンドユーザーの認証が ISO/IEC 29115 の要件を満たしていないことを示します。 |
amr |
文字列のJSON配列、v1.0 トークンにのみ存在する | トークンのサブジェクトが認証された方法を示します。 |
appid |
文字列、GUID、v1.0 トークンにのみ存在する | トークンを使用するクライアントのアプリケーションID。 アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。 アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Azure AD 内のサービス プリンシパル オブジェクトを表すこともできます。 |
azp |
文字列、GUID、v2.0 トークンにのみ存在する | appid に代わるものです。 トークンを使用するクライアントのアプリケーションID。 アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。 アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Azure AD 内のサービス プリンシパル オブジェクトを表すこともできます。 |
appidacr |
文字列、「0」、「1」または 「2」、v1.0 トークンにのみ存在する |
クライアントが認証された方法を示します。 パブリック クライアントの場合、値は "0" です。 クライアント ID とクライアント シークレットが使用されている場合、値は "1" です。 クライアント証明書が認証に使用された場合、値は 「2」です。 |
azpacr |
文字列、「0」、「1」または 「2」、v2.0 トークンにのみ存在する |
appidacr に代わるものです。 クライアントが認証された方法を示します。 パブリック クライアントの場合、値は "0" です。 クライアント ID とクライアント シークレットが使用されている場合、値は "1" です。 クライアント証明書が認証に使用された場合、値は "2" です。 |
preferred_username |
文字列、v2.0 トークンにのみ存在する | ユーザーを表すプライマリ ユーザー名です。 この値には、電子メール アドレス、電話番号、または指定された書式のない一般的なユーザー名を指定できます。 その値は、変更可能であり、時間の経過と共に変化することがあります。 この値は変更可能であるため、認可の決定には使用できません。 ただし、この値を、ユーザー名のヒントとして使用することや、人間が判読できる UI でユーザー名として使用することができます。 この要求を受け取るには、 profile スコープが必要です。 |
name |
String | トークンのサブジェクトを識別する、人間が判読できる値を提供します。 この値は、一意であるとは限らず、変更可能であり、表示目的でのみ使用されます。 この要求を受け取るには、 profile スコープが必要です。 |
scp |
文字列、スコープのスペース区切りリスト | クライアント アプリケーションが同意を要求し、同意を得た、アプリケーションによって公開されているスコープのセット。 アプリケーションでは、これらのスコープがアプリケーションによって公開されている有効なスコープであることを確認し、これらのスコープの値に基づいて認可を決定する必要があります。 ユーザー トークンにのみ含まれます。 |
roles |
文字列の配列、アクセス許可の一覧 | 要求元のアプリケーションまたはユーザーに呼び出しのアクセス許可が付与されている、アプリケーションによって公開されているアクセス許可のセット。 アプリケーション トークンでは、このアクセス許可のセットはユーザー スコープの代わりにクライアント資格情報フローで使用されます。 ユーザー トークンでは、この値のセットにはターゲット アプリケーションでユーザーに割り当てられたロールが設定されます。 |
wids |
RoleTemplateID GUID の配列 | Azure AD 組み込みロールに存在するロールのセクションから、このユーザーに割り当てられたテナント全体のロールを示します。 この要求は、アプリケーション マニフェストの groupMembershipClaims プロパティを介して、アプリケーションごとに構成されます。 これを All または DirectoryRole に設定することが必要です。 トークンの長さの問題のため、暗黙的フローを介して取得されたトークンには存在しない可能性があります。 |
groups |
GUID の JSON 配列 | サブジェクトのグループ メンバーシップを表すオブジェクト ID です。 これらの値は一意であり、アクセスの管理 (リソースへのアクセスに認可を適用するなど) に安全に使用することができます。 groups 要求に含まれるグループは、アプリケーション マニフェストの groupMembershipClaims プロパティを使用してアプリケーションごとに構成されます。 値が null の場合はすべてのグループが除外され、値が SecurityGroup の場合は Active Directory セキュリティ グループのメンバーシップのみが含まれ、値が All の場合はセキュリティ グループと Microsoft 365 配布リストの両方が含まれます。 暗黙的な許可での groups 要求の使用の詳細については、hasgroups 要求を参照してください。 他のフローでは、ユーザーが属するグループの数が上限 (SAML の場合は 150、JWT の場合は 200) を超えた場合、Azure AD によって要求ソースに超過要求が追加されます。 要求ソースは、ユーザーのグループのリストを含む Microsoft Graph エンドポイントを参照します。 |
hasgroups |
Boolean | 存在する場合、常に true であり、ユーザーが 1 つ以上のグループに属しているかどうかを示します。 すべてのグループ要求で URL 長の制限 (現在は 6 以上のグループ) を超えて URI フラグメントが拡張された場合、暗黙的な許可フローの JWT で groups 要求の代わりに使用されます。 クライアントが Microsoft Graph API を使用して、ユーザーのグループ (https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects) を決定する必要があることを示します。 |
groups:src1 |
JSON オブジェクト | 長さは制限されていない (hasgroups を参照) が、まだトークンには大きすぎるトークン要求の場合は、そのユーザーの完全なグループ リストへのリンクが含まれます。 SAML では groups 要求の代わりに新しい要求として、JWT では分散要求として使用されます。 JWT 値の例: "groups":"src1" "_claim_sources: "src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" } |
sub |
String | トークンが情報をアサートするプリンシパル (アプリケーションのユーザーなど)。 この値は変更不可で、再割り当ても再利用もできません。 そのため、この値を使用すると、トークンを使用してリソースにアクセスする場合などに安全に承認チェックができます。また、データベース テーブルのキーとして使用することもできます。 サブジェクトは、Azure AD が発行するトークン内に常に存在するため、汎用性のある認可システムでこの値を使用します。 ただし、サブジェクトは特定のアプリケーション ID に一意であるペアワイズ識別子です。 1 人のユーザーが 2 つの異なるクライアント ID を使用して 2 つの異なるアプリケーションにサインインすると、そのアプリケーションは、サブジェクト要求に対して 2 つの異なる値を受け取ります。 2 つの異なる値が求められているかどうかは、アーキテクチャやプライバシーの要件によって異なります。 oid 要求 (テナント内のアプリケーション全体で同じままです) も参照してください。 |
oid |
文字列、GUID | 要求元の不変 IDで、ID の有効性が確認済みのユーザーまたはサービス プリンシパル。 承認チェックの安全に実行するとき、また、データベース テーブルのキーとして使用することもできます。 この ID によって、複数のアプリケーションで要求元が一意に識別されます。 同じユーザーにサインインする 2 つの異なるアプリケーションは oid 要求で同じ値を受け取ります。 Microsoft Graph などの Microsoft オンライン サービスに対してクエリを実行するときに oid を使用できます。 Microsoft Graph は、この ID を、指定されたユーザー アカウントの id プロパティとして返します。 oid では複数のアプリケーションがプリンシパルを関連付けることができるため、ユーザーがこの要求を受け取るには、profile スコープが必要です。 1 人のユーザーが複数のテナントに存在する場合、そのユーザーのオブジェクト ID はテナントごとに異なります。 そのユーザーが同じ資格情報で各アカウントにログインしても、それぞれ異なるアカウントと見なされます。 |
tid |
文字列、GUID | ユーザーがサインインしているテナントを表します。 職場または学校アカウントの場合、GUID はユーザーがサインインしている組織の不変のテナント ID です。 個人用 Microsoft アカウント テナント (Xbox、Teams for Life、Outlook のようなサービス) へのサインインの場合、値は 9188040d-6c67-4c5b-b112-36a304b66dad です。 この要求を受け取るには、アプリケーションが profile スコープを要求する必要があります。 |
unique_name |
文字列、v1.0 トークンにのみ存在する | トークンのサブジェクトを識別する、人が判読できる値を提供します。 この値は、テナント内で一意であることが保証されているわけではなく、表示目的でのみ使用する必要があります。 |
uti |
String | トークン識別子要求。JWT 仕様の jti と同等です。 大文字と小文字を区別する一意のトークンごとの識別子。 |
rh |
あいまいな文字列 | Azure がトークンの再検証に使用する内部要求。 リソースでこの要求を使用しないでください。 |
ver |
文字列、1.0 または 2.0 |
アクセス トークンのバージョンを示します。 |
グループ超過要求
Azure AD では、グループ要求に含まれるオブジェクト ID の数が、HTTP ヘッダーのサイズ制限内に収まるように制限されます。 超過制限 (SAML トークンの場合は 150、JWT トークンの場合は 200、暗黙的フローを使用して発行される場合は 6 のみ) を超えるグループのメンバーにユーザーがなっている場合、Azure AD は、グループ要求をトークンに出力しません。 代わりに、Microsoft Graph API に照会してユーザーのグループ メンバーシップを取得するようアプリケーションに指示する超過要求がトークンに追加されます。
{
...
"_claim_names": {
"groups": "src1"
},
"_claim_sources": {
"src1": {
"endpoint": "[Url to get this user's group membership from]"
}
}
...
}
超過のシナリオは、App Creation Scripts フォルダーにある BulkCreateGroups.ps1 を使用してテストします。
v1.0 の基本要求
次の要求は、該当する場合は v1.0 トークンに含まれますが、既定では v2.0 トークンには含まれません。 v2.0 に対してこれらの要求を使用するために、アプリケーションの要求では省略可能な要求が使用されます。
| 要求 | Format | 説明 |
|---|---|---|
ipaddr |
String | ユーザーが認証された IP アドレス。 |
onprem_sid |
文字列 (SID 形式) | ユーザーがオンプレミス認証を行った場合、この要求によって SID が提供されます。 レガシ アプリケーションでの承認にこの要求を使用できます。 |
pwd_exp |
int、Unix タイムスタンプ | ユーザーのパスワードの有効期限を示します。 |
pwd_url |
String | パスワードをリセットするためにユーザーを送信できる URL。 |
in_corp |
boolean | クライアントが企業ネットワークからサインインしている場合に通知します。 そうでない場合、この要求は含まれません。 |
nickname |
String | ユーザーの別の名前。姓または名とは別の名前です。 |
family_name |
String | ユーザー オブジェクトで定義されたユーザーの姓を示します。 |
given_name |
String | ユーザー オブジェクトに設定されたユーザーの名を示します。 |
upn |
String | ユーザーのユーザー名。 電話番号、電子メール アドレス、または書式なし文字列を指定できます。 表示目的でのみ使用し、再認証のシナリオでユーザー名のヒントを提供する必要があります。 |
amr 要求
ID は、アプリケーションに関連している可能性のあるさまざまな方法で認証できます。 amr 要求は、パスワードと Authenticator アプリの両方を使用した認証用に、複数の項目を格納できる配列 (["mfa", "rsa", "pwd"] など) です。
| 値 | 説明 |
|---|---|
pwd |
パスワード認証。ユーザーの Microsoft パスワードまたはアプリのクライアント シークレット。 |
rsa |
Microsoft Authenticator アプリを使用した認証など、認証が RSA キーの証明に基づいていたことを示します。 この値は、サービスが所有する X509 証明書を使用して自己署名 JWT によって認証が行われたかどうかも示します。 |
otp |
電子メールまたはテキスト メッセージを使用したワンタイム パスコード。 |
fed |
フェデレーション認証アサーション (JWT や SAML など) が使用されたことを示します。 |
wia |
Windows 統合認証 |
mfa |
多要素認証が使用されました。 この要求が存在する場合は、他の認証方法が含まれます。 |
ngcmfa |
mfa と同等です。特定の高度な資格情報の種類のプロビジョニングに使用されます。 |
wiaormfa |
ユーザーが Windows 資格情報または MFA 資格情報を使用して認証されたことを示します。 |
none |
認証は実行されませんでした。 |
アクセス トークンの有効期間
アクセス トークンの既定の有効期間は、可変です。 発行されると、アクセス トークンの既定の有効期間には、60 分から 90 分 (平均 75 分) の範囲のランダムな値が割り当てられます。 このバリエーションによって、期間内にアクセス トークンの要求が分散してサービスの回復性が向上します。これで、Azure AD へのトラフィックが 1 時間ごとに急増することを防止します。
条件付きアクセスを使用しないテナントでは、Microsoft Teams や Microsoft 365 などのクライアントに対して、既定のアクセス トークンの有効期間が 2 時間に設定されています。
アクセス トークンの有効期間を調整して、クライアント アプリケーションがアプリケーション セッションを期限切れにする頻度、およびユーザーを再認証する (自動的にまたは対話形式で) ように要求する頻度を制御できます。 既定のアクセス トークンの有効期間のバリエーションをオーバーライドするには、構成可能なトークンの有効期間 (CTL) を使用して、静的な既定のアクセス トークンの有効期間を設定します。
既定のトークンの有効期間のバリエーションは、継続的アクセス評価 (CAE) が有効になっている組織に適用されます。 既定のトークンの有効期間のバリエーションは、組織が CTL ポリシーを使用している場合でも適用されます。 有効期間が長いトークンの既定のトークンの有効期間の範囲は、20 時間から 28 時間です。 アクセス トークンの有効期限が切れると、クライアントは更新トークンを使用して新しい更新トークンとアクセス トークンを取得する必要があります。
条件付きアクセスのサインイン頻度 (SIF) を使用してサインインの頻度を適用する組織は、既定のアクセス トークンの有効期間のバリエーションをオーバーライドすることはできません。 組織が SIF を使用する場合、クライアントの資格情報プロンプトの間隔は、トークンの有効期間 (60 分から 90 分の範囲) に、サインイン頻度の間隔を加算したものになります。
既定のトークンの有効期間のバリエーションがサインイン頻度とどのように連動するかの例を次に示します。 たとえば、組織で 1 時間ごとにサインイン頻度が発生するように設定します。 トークンは、(トークンの有効期間のバリエーションにより) 60 分から 90 分の有効期間で発行されるため、実際のサインイン間隔は 1 時間から 2.5 時間の間に発生します。
1 時間の有効期間があるトークンを持つユーザーが、(サインイン頻度を超える直前である) 59 分に対話型サインインを実行する場合、サインインは SIF しきい値を下回るため、資格情報のプロンプトは表示されません。 有効期間が 90 分の新しいトークンが発行された場合、ユーザーには、1 時間半の間に資格情報プロンプトは表示されません。 90 分のトークン有効期間のサイレント更新を実行しようとすると、セッションの長さの合計が 1 時間のサインイン頻度設定を超えているため、Azure AD には資格情報プロンプトが必要になります。 この例では、SIF 間隔とトークンの有効期間のバリエーションが原因で、資格情報プロンプトの時間差は 2.5 時間になります。
トークンを検証する
すべてのアプリケーションでトークンを検証する必要はありません。 アプリケーションでトークンを検証する必要があるのは、特定のシナリオのみです。
- Web API は、クライアントから自身に送信されたアクセス トークンを検証する必要があります。
aud要求を含むトークンのみを受け入れる必要があります。 - ASP.NET Core のような機密性の高い Web アプリケーションは、ユーザーのデータへのアクセスを許可したり、セッションを確立したりする前に、ハイブリッド フローでユーザーのブラウザーを使用して自身に送信された ID トークンを検証する必要があります。
上記のシナリオのいずれにも当てはまらない場合、アプリケーションはトークンの検証からメリットを受けることはなく、トークンの有効性に基づいて判断が行われた場合、セキュリティと信頼性のリスクが発生する可能性があります。 ネイティブ アプリケーションやシングルページ アプリケーションのようなパブリック クライアントは、SSL 保護によってトークンが有効であることが保証される IDP と直接通信するため、トークンの検証からメリットを受けることはありません。
API と Web アプリケーションは、アプリケーションに一致する aud 要求を含むトークンのみを検証する必要があります。 その他のリソースには、カスタム トークン検証規則がある場合があります。 たとえば、Microsoft Graph のトークンは、専用の形式であるため、これらの規則に従って検証することはできません。 別のリソースを対象とするトークンを検証して受け入れることは、混乱した使節 (Confused Deputy) の問題にたとえることができます。
アプリケーションで ID トークンまたはアクセス トークンを検証する必要がある場合は、最初に OpenID 探索ドキュメントの値と突き合わせてトークンの署名と発行者を検証する必要があります。 たとえば、テナントに依存しないバージョンのドキュメントは https://login.microsoftonline.com/common/.well-known/openid-configuration にあります。
Azure AD ミドルウェアにはアクセス トークンを検証するための機能が組み込まれており、適切な言語のサンプルを参照できます。 JWT の検証に使用できるサードパーティのオープン ソース ライブラリもいくつか存在します。 Azure AD 認証ライブラリとコード サンプルの詳細については、認証ライブラリに関する記事を参照してください。
署名の検証
JWT には 3 つのセグメントがあり、 . 文字で区切られています。 1 番目のセグメントはヘッダー、2 番目は本文、3 番目は署名と呼ばれます。 署名セグメントを使用してトークンの信頼性を検証し、アプリケーションで信頼できることを確認できます。
Azure AD によって発行されるトークンは、RS256 などの業界標準の非対称暗号アルゴリズムを使用して署名されます。 JWT のヘッダーには、トークンの署名に使用されたキーと暗号方法に関する情報が含まれます。
{
"typ": "JWT",
"alg": "RS256",
"x5t": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk",
"kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"
}
alg 要求はトークンへの署名に使用されたアルゴリズムを示し、kid 要求はトークンへの検証に使用された特定の公開キーを示します。
いつでも、Azure AD は公開/秘密キー ペアの特定セットのいずれかを使用して、ID トークンに署名できます。 Azure AD は定期的に使用可能なキー セットをローテーションするので、このキー変更を自動的に処理するようにアプリケーションを作成する必要があります。 Azure AD によって使用される公開キーの更新を確認する適切な頻度は、24 時間間隔です。
署名の検証に必要な署名キー データは、次の場所にある OpenID Connect メタデータのドキュメントを使用して入手します。
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
ヒント
ブラウザーで URL を試します
次の情報では、メタデータ ドキュメントについて説明します。
- OpenID Connect 認証を実行するために必要なさまざまなエンドポイントの場所などの、いくつかの有効な情報を含む JSON オブジェクトです。
jwks_uriが含まれています。これは、トークンの署名に使用される秘密キーに対応する公開キーのセットの場所を示すものです。jwks_uriにある JSON Web キー (JWK) には、特定の時点で使用されているすべての公開キー情報が含まれます。 JWK 形式については RFC 7517 を参照してください。 アプリケーションには、JWT ヘッダーのkid要求を使用し、このドキュメントから、特定のトークンの署名に使用された秘密キーに対応する公開キーを選択できます。 その後、正しい公開キーと指定されたアルゴリズムを使用して、署名の検証を実行できます。
注意
kid 要求を使用してトークンを検証します。 v1.0 トークンには x5t と kid の両方の要求が含まれますが、v2.0 トークンには kid 要求のみ含まれます。
署名の検証を実行する方法については、このドキュメントでは説明していません。 必要に応じて、署名の検証に役立つオープン ソース ライブラリが多数存在します。 ただし、Microsoft ID プラットフォームには、標準に対する 1 つのトークン署名拡張であるカスタム署名キーがあります。
claims-mapping 機能を使用した結果としてアプリケーションにカスタム署名キーがある場合は、アプリケーションの署名キー情報 (検証に使用する必要があります) を指す jwks_uri を取得するために、アプリケーション ID を含む appid クエリ パラメーターを追加します。 例: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e には、https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e の jwks_uri が含まれます。
クレーム ベースの承認
アプリケーションのビジネス ロジックによって、要求ベースの認可が決定されます。 いくつかの一般的な認可方法を次に示します。
トークンを検証する
aud 要求を使用して、ユーザーがアプリケーションの呼び出しを意図していることを確認します。 リソースの識別子が aud 要求に含まれていない場合は、それを拒否します。
アクセス許可を検証する
roles と wids の要求を使用して、ユーザーが API を呼び出す権限を持っていることを検証します。 たとえば、管理者は API への書き込みアクセス許可を持っていますが、一般ユーザーは持っていないなどです。 トークン内の tid が、API にデータを格納するために使用されるテナント ID と一致することを確認します。
ユーザーがあるテナントから API にデータを格納する場合、そのデータにアクセスするには、そのテナントに再度サインインする必要があります。 あるテナント内のデータへの、別のテナントからのアクセスを許可しないでください。
amr 要求を使用して、ユーザーが MFA を実行したことを確認します。 MFA の適用は、条件付きアクセスを使用して行われます。 アクセス トークンで roles または groups 要求を要求した場合は、ユーザーが、このアクションの実行を許可されているグループに属していることを確認します。
暗黙的フローを使用してトークンを取得した場合、このデータは大きすぎてトークンに収まらないことが多いため、データを Microsoft Graph に照会します。
アクセス トークン内のユーザーがデータにアクセスできるかどうかを判断するために、email または upn 要求値を使用しないでください。 このような変更可能な要求値は時間の経過と共に変わることがあり、認可のために安全ではなくなり、信頼性が低くなくなります。
API のデータを一意に識別し、そのデータへのアクセス権をユーザーに付与するかどうかを決定するために、キーの組み合わせとして、変更できない要求値 tid と sub または oid を使用します。
- 適切:
tid+sub - より適切:
tid+oid-oidはアプリケーション間で一貫しているため、アプリケーションのエコシステムでは、データへのユーザー アクセスを監査できます。
データを一意に識別するために、email や upn のような変更可能で人間が判読できる ID を使用しないでください。
アプリケーションのサインインを検証する
scp要求を使用して、呼び出し側アプリに API を呼び出すアクセス許可をユーザーが付与したことを確認します。appid要求 (v1.0 トークンの場合) またはazp要求 (v2.0 トークンの場合) を使用して、呼び出し元のクライアントが API の呼び出しを許可されていることを確認します。- これらの要求 (
appid、azp) を検証する必要があるのは、事前に決定されたアプリケーション (基幹業務アプリケーションや既知のフロントエンドによって呼び出される Web API など) によってのみ Web API が呼び出されるように制限する場合だけです。 呼び出し元アプリケーションからのアクセスを許可することを目的とした API では、これらの要求を検証する必要はありません。
- これらの要求 (
ユーザー トークンとアプリケーション トークン
アプリケーションでは、ユーザー用トークンを受信するか、クライアント資格情報フローを通じてアプリケーションから直接受信します。 これらのアプリ専用トークンは、この呼び出しがアプリケーションからのものであり、その背後にユーザーがいないことを示します。 これらのトークンは、ほぼ同じように処理されます。
- トークンのサブジェクトに付与されているアクセス許可を確認するには、
rolesを使用します。 oidまたはsubを使用して、呼び出し元のサービス プリンシパルが想定されているものであることが検証されます。
アプリケーションでアプリ専用アクセス トークンとユーザー用アクセス トークンを区別する必要がある場合は、idtyp オプション要求が使用されます。 アプリ専用アクセス トークンを検出するには、accessToken フィールドに idtyp 要求を追加し、値 app を確認します。 ユーザー用の ID トークンとアクセス トークンには、idtyp 要求は含まれません。
トークンの失効
更新トークンは、さまざまな理由でいつでも無効にしたり、取り消したりできます。 理由は、タイムアウトと失効のカテゴリに分類されます。
トークンのタイムアウト
トークンの有効期間の構成を使用する組織は、更新トークンの有効期間を変更できます。 トークンの中には、使用されずに消えてしまうものもありあす。 たとえば、ユーザーがアプリを 3 か月間開かずに、トークンの有効期限が切れた場合です。 アプリケーションでは、ログイン サーバーが期限切れのために更新トークンを拒否するシナリオが発生する可能性があります。
- MaxInactiveTime: 更新トークンが MaxInactiveTime で指示された時間内に使用されなかった場合、更新トークンは無効になります。
- MaxSessionAge: MaxAgeSessionMultiFactor または MaxAgeSessionSingleFactor が既定値 (Until-revoked) 以外に設定されている場合、MaxAgeSession* に設定された時間が経過すると、再認証が必要になります。 例 :
- テナントの MaxInactiveTime が 5 日で、ユーザーが 1 週間の休暇を取った場合、7 日間にわたり Azure AD はユーザーからの新しいトークン要求を認識しません。 ユーザーが次に新しいトークンを要求するとき、更新トークンが失効していることがわかります。資格情報を再び入力する必要があります。
- 機密性の高いアプリケーションの MaxAgeSessionSingleFactor は 1 日に設定されています。 ユーザーが月曜日にログインし、次に火曜日 (25 時間が経過した後) にログインした場合は、再認証が必要になります。
トークンの無効化
更新トークンは、資格情報の変更、または管理アクションにより、サーバーによって取り消される場合があります。 更新トークンには、機密クライアントと、パブリック クライアントのクラスがあります。
| Change | パスワードに基づくクッキー | パスワードに基づくトークン | パスワードに基づかないクッキー | パスワードに基づかないトークン | 機密のクライアントのトークン |
|---|---|---|---|---|---|
| パスワードが期限切れ | 存続 | 存続 | 存続 | 存続 | 存続 |
| ユーザーによるパスワードの変更 | 取り消し | 取り消し | 存続 | 存続 | 存続 |
| ユーザーがSSPRである | 取り消し | 取り消し | 存続 | 存続 | 存続 |
| 管理者によるパスワードのリセット | 取り消し | 取り消し | 存続 | 存続 | 存続 |
| ユーザーが PowerShell を使用して更新トークンを無効にする | 取り消し | 取り消し | 取り消し | 取り消し | 取り消し |
| 管理者が PowerShell を使用してユーザーのすべての更新トークンを無効にする | 取り消し | 取り消し | 取り消し | 取り消し | 取り消し |
| Web でのシングル サインアウト | 取り消し | 存続 | 取り消し | 存続 | 存続 |
パスワードに基づかない
"パスワードに基づかない" ログインは、ユーザーがそれを取得する際にパスワードを入力しないことを意味します。 パスワードに基づかないログインの例を次に示します。
- 顔を使用する Windows Hello
- FIDO2 キー
- SMS
- 音声
- PIN
詳しくは、プライマリ更新トークンに関する記事をご覧ください。
次のステップ
- Azure AD の
id_tokensの詳細を確認します。 - アクセス許可と同意の詳細を確認します。