Microsoft ID プラットフォーム アクセス トークンMicrosoft identity platform access tokens

アクセス トークンにより、クライアントは Azure によって保護された API を安全に呼び出すことができます。Access tokens enable clients to securely call APIs protected by Azure. Microsoft ID プラットフォーム アクセス トークンは JWT、つまり Azure によって署名された Base64 でエンコードされた JSON オブジェクトです。Microsoft identity platform access tokens are JWTs, Base64 encoded JSON objects signed by Azure. アクセス トークンの内容は特定のリソースのみを対象としているため、クライアントはトークンを不透明型の文字列として扱う必要があります。Clients should treat access tokens as opaque strings, as the contents of the token are intended for the resource only. 検証とデバッグを目的として、開発者は jwt.ms などのサイトを使用して、JWT をデコードすることができます。For validation and debugging purposes, developers can decode JWTs using a site like jwt.ms. クライアントは、さまざまなプロトコルを使用して、v1.0 エンドポイントまたは v2.0 エンドポイントのどちらからでもアクセス トークンを取得できます。Your client can get an access token from either the v1.0 endpoint or the v2.0 endpoint using a variety of protocols.

クライアントがアクセス トークンを要求すると、Azure AD も、アプリで消費されるそのアクセス トークンに関する何らかのメタデータを返します。When your client requests an access token, Azure AD also returns some metadata about the access token for your app's consumption. この情報には、アクセス トークンの有効期限や、それが有効なスコープが含まれます。This information includes the expiry time of the access token and the scopes for which it's valid. このデータを使用すると、アプリはアクセス トークン自体を解析しなくても、そのアクセス トークンのインテリジェントなキャッシュを実行できます。This data allows your app to do intelligent caching of access tokens without having to parse the access token itself.

ご自分のアプリケーションが、クライアントからアクセス要求が可能なリソース (Web API) である場合、アクセス トークンを使って、認証と承認に使用する有用な情報 (ユーザー、クライアント、発行元、アクセス許可など) を提供できます。If your application is a resource (web API) that clients can request access to, access tokens provide helpful information for use in authentication and authorization, such as the user, client, issuer, permissions, and more.

リソースでアクセス トークン内のクレームを検証して使用する方法については、以下のセクションをご覧ください。See the following sections to learn how a resource can validate and use the claims inside an access token.

重要

アクセス トークンは、トークンの対象ユーザー、つまりそのトークン内のスコープを所有するアプリケーションに基づいて作成されます。Access tokens are created based on the audience of the token, meaning the application that owns the scopes in the token. これは、アプリ マニフェスト内の accessTokenAcceptedVersion2 に設定しているリソースにより、v1.0 エンドポイントを呼び出しているクライアントがどのように v2.0 アクセス トークンを受信できるかを示しています。This is how a resource setting accessTokenAcceptedVersion in the app manifest to 2 allows a client calling the v1.0 endpoint to receive a v2.0 access token. 同様に、これはクライアントのアクセス トークンの省略可能な要求を変更しても、MS Graph リソースによって所有される user.read に対してトークンが要求されたときに受信されるアクセス トークンが変更されない理由でもあります。Similarly, this is why changing the access token optional claims for your client do not change the access token received when a token is requested for user.read, which is owned by the MS Graph resource.
同じ理由で、個人アカウント (hotmail.com や outlook.com など) によるクライアント アプリケーションをテストしたときに、クライアントが受け取ったアクセス トークンが不透明型の文字列であることがわかります。For the same reason, while testing your client application with a personal account (such as hotmail.com or outlook.com), you may find that the access token received by your client is an opaque string. これは、アクセス対象のリソースが、暗号化されていてクライアントが認識できない従来の MSA (Microsoft アカウント) チケットを要求したためです。This is because the resource being accessed has requested legacy MSA (Microsoft account) tickets that are encrypted and can't be understood by the client.

サンプル トークンSample tokens

v1.0 トークンと v2.0 トークンは似ており、同じクレームが多く含まれています。v1.0 and v2.0 tokens look similar and contain many of the same claims. 各トークンの例を次に示します。An example of each is provided here.

v1.0v1.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd

この v1.0 トークンは JWT.ms で表示できます。View this v1.0 token in JWT.ms.

v2.0v2.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

この v2.0 トークンは JWT.ms で表示できます。View this v2.0 token in JWT.ms.

アクセス トークン内のクレームClaims in access tokens

JWT は次の 3 つの部分に分かれています。JWTs are split into three pieces:

  • ヘッダー - トークンの種類や署名方法に関する情報など、トークンの検証方法に関する情報が提供されます。Header - Provides information about how to validate the token including information about the type of token and how it was signed.
  • ペイロード - サービスを呼び出そうとしているユーザーまたはアプリに関する重要なデータがすべて含まれています。Payload - Contains all of the important data about the user or app that is attempting to call your service.
  • 署名 - トークンの検証に使用される原材料です。Signature - Is the raw material used to validate the token.

各部分はピリオド (.) で区切られ、Base64 で個別にエンコードされます。Each piece is separated by a period (.) and separately Base64 encoded.

クレームは、そこに入力される値が存在する場合にのみ存在します。Claims are present only if a value exists to fill it. そのため、アプリはクレームの存在に依存することはできません。So, your app shouldn't take a dependency on a claim being present. 例として、pwd_exp (すべてのテナントがパスワードを期限切れにする必要があるわけではありません) や、family_name (名前のないアプリケーションに代わって、クライアント資格情報フローが使用されます) などがあります。Examples include pwd_exp (not every tenant requires passwords to expire) or family_name (client credential flows are on behalf of applications, which don't have names). アクセス トークンの検証に使用されるクレームは常に存在します。Claims used for access token validation will always be present.

注意

再利用に備え、Azure AD を使ったトークンのセキュリティ保護に活用されるクレームもあります。Some claims are used to help Azure AD secure tokens in case of reuse. これらは公開されないものとして、記述で "Opaque" としてマークされます。These are marked as not being for public consumption in the description as "Opaque". これらのクレームはトークンに表示される場合とされない場合があり、新しいものが予告なく追加される場合もあります。These claims may or may not appear in a token, and new ones may be added without notice.

ヘッダーのクレームHeader claims

要求Claim 形式Format 説明Description
typ 文字列 - 常に "JWT"String - always "JWT" トークンが JWT であることを示します。Indicates that the token is a JWT.
nonce StringString トークン リプレイ攻撃から保護するために使用される一意識別子。A unique identifier used to protect against token replay attacks. リソースでこの値を記録することで、再生を防ぐことができます。Your resource can record this value to protect against replays.
alg StringString トークンの署名に使用されたアルゴリズム ("RS256" など) を示します。Indicates the algorithm that was used to sign the token, for example, "RS256"
kid StringString このトークンの署名に使用されている公開キーの拇印が記述されています。Specifies the thumbprint for the public key that's used to sign this token. v1.0 と v2.0 のどちらのアクセス トークンでも生成されます。Emitted in both v1.0 and v2.0 access tokens.
x5t StringString kid と同様に機能します (使用方法も値も同じ)。Functions the same (in use and value) as kid. x5t は、互換性を目的として v1.0 アクセス トークンでのみ生成されるレガシ クレームです。x5t is a legacy claim emitted only in v1.0 access tokens for compatibility purposes.

ペイロードのクレームPayload claims

要求Claim 形式Format 説明Description
aud 文字列、アプリケーション ID/URIString, an App ID URI トークンの受信者を示します。Identifies the intended recipient of the token. ID トークンでは、オーディエンスは Azure portal でアプリに割り当てられたアプリのアプリケーション ID です。In id tokens, the audience is your app's Application ID, assigned to your app in the Azure portal. アプリでは、この値を検証し、値が一致しない場合はトークンを拒否する必要があります。Your app should validate this value and reject the token if the value does not match.
iss 文字列、STS URIString, an STS URI トークンを作成して返したセキュリティ トークン サービス (STS)、およびユーザーが認証された Azure AD テナントを示します。Identifies the security token service (STS) that constructs and returns the token, and the Azure AD tenant in which the user was authenticated. 発行されたトークンが v2.0 トークンである場合 (ver 要求を参照)、URI は /v2.0 で終了します。If the token issued is a v2.0 token (see the ver claim), the URI will end in /v2.0. ユーザーが Microsoft アカウントを持つコンシューマー ユーザーであることを示す GUID は 9188040d-6c67-4c5b-b112-36a304b66dad です。The GUID that indicates that the user is a consumer user from a Microsoft account is 9188040d-6c67-4c5b-b112-36a304b66dad. 要求の GUID 部分を使用して、アプリにサインインできるテナントのセットを制限します (該当する場合)。Your app should use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable.
idp 文字列 (通常は STS URI)String, usually an STS URI トークンのサブジェクトを認証した ID プロバイダーを記録します。Records the identity provider that authenticated the subject of the token. この値は、発行者とテナントが異なるユーザー アカウント (たとえばゲスト) の場合を除いて、発行者クレームの値と同じです。This value is identical to the value of the Issuer claim unless the user account not in the same tenant as the issuer - guests, for instance. クレームが存在しない場合は、代わりに iss の値を使用できることを示しています。If the claim isn't present, it means that the value of iss can be used instead. 個人用アカウントが組織のコンテキストで使用されている場合 (たとえば、個人用アカウントが Azure AD テナントに招待された場合)、idp 要求は 'live.com' または Microsoft アカウント テナント 9188040d-6c67-4c5b-b112-36a304b66dad を含む STS URI である可能性があります。For personal accounts being used in an organizational context (for instance, a personal account invited to an Azure AD tenant), the idp claim may be 'live.com' or an STS URI containing the Microsoft account tenant 9188040d-6c67-4c5b-b112-36a304b66dad.
iat int、UNIX タイムスタンプint, a UNIX timestamp "Issued At" は、このトークンの認証がいつ行われたのかを示します。"Issued At" indicates when the authentication for this token occurred.
nbf int、UNIX タイムスタンプint, a UNIX timestamp "nbf" (not before) 要求は JWT が有効になる日時を示します。これ以前にその JWT を受け入れて処理することはできません。The "nbf" (not before) claim identifies the time before which the JWT must not be accepted for processing.
exp int、UNIX タイムスタンプint, a UNIX timestamp "exp" (expiration time) 要求は、JWT の有効期限を示します。これ以降は、その JWT を受け入れて処理することはできません。The "exp" (expiration time) claim identifies the expiration time on or after which the JWT must not be accepted for processing. この日時より前でも、リソースがトークンを拒否する場合があることに注意してください。たとえば、認証での変更が必要な場合や、トークンの失効が検出された場合です。It's important to note that a resource may reject the token before this time as well, such as when a change in authentication is required or a token revocation has been detected.
aio 不透明な文字列Opaque String Azure AD がトークンの再利用のためにデータの記録に使用する内部要求。An internal claim used by Azure AD to record data for token reuse. リソースでこの要求を使用しないでください。Resources should not use this claim.
acr 文字列、"0" または "1"String, a "0" or "1" v1.0 トークンにのみ存在します。Only present in v1.0 tokens. "認証コンテキスト クラス" 要求。The "Authentication context class" claim. 値 「0」 は、エンドユーザーの認証が ISO/IEC 29115 の要件を満たしていないことを示します。A value of "0" indicates the end-user authentication did not meet the requirements of ISO/IEC 29115.
amr 文字列の JSON 配列JSON array of strings v1.0 トークンにのみ存在します。Only present in v1.0 tokens. トークンのサブジェクトが認証された方法を示します。Identifies how the subject of the token was authenticated. 詳細については、「amr 要求」をご覧ください。See the amr claim section for more details.
appid 文字列、GUIDString, a GUID v1.0 トークンにのみ存在します。Only present in v1.0 tokens. トークンを使用するクライアントのアプリケーションID。The application ID of the client using the token. アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。The application can act as itself or on behalf of a user. アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Azure AD 内のサービス プリンシパル オブジェクトを表すこともできます。The application ID typically represents an application object, but it can also represent a service principal object in Azure AD.
appidacr "0"、"1"、または "2""0", "1", or "2" v1.0 トークンにのみ存在します。Only present in v1.0 tokens. クライアントが認証された方法を示します。Indicates how the client was authenticated. パブリック クライアントの場合、値は "0" です。For a public client, the value is "0". クライアント ID とクライアント シークレットが使用されている場合、値は "1" です。If client ID and client secret are used, the value is "1". クライアント証明書が認証に使用された場合、値は "2" です。If a client certificate was used for authentication, the value is "2".
azp 文字列、GUIDString, a GUID V2.0 トークンにのみ存在します。appid に代わるものです。Only present in v2.0 tokens, a replacement for appid. トークンを使用するクライアントのアプリケーションID。The application ID of the client using the token. アプリケーションとして識別することもできますが、アプリケーションを使用しているユーザーとして識別することもできます。The application can act as itself or on behalf of a user. アプリケーション ID は通常、アプリケーション オブジェクトを表しますが、Azure AD 内のサービス プリンシパル オブジェクトを表すこともできます。The application ID typically represents an application object, but it can also represent a service principal object in Azure AD.
azpacr "0"、"1"、または "2""0", "1", or "2" V2.0 トークンにのみ存在します。appidacr に代わるものです。Only present in v2.0 tokens, a replacement for appidacr. クライアントが認証された方法を示します。Indicates how the client was authenticated. パブリック クライアントの場合、値は "0" です。For a public client, the value is "0". クライアント ID とクライアント シークレットが使用されている場合、値は "1" です。If client ID and client secret are used, the value is "1". クライアント証明書が認証に使用された場合、値は "2" です。If a client certificate was used for authentication, the value is "2".
preferred_username stringString ユーザーを表すプライマリ ユーザー名です。The primary username that represents the user. 電子メール アドレス、電話番号、または指定された書式のない一般的なユーザー名を指定できます。It could be an email address, phone number, or a generic username without a specified format. その値は、変更可能であり、時間の経過と共に変化することがあります。Its value is mutable and might change over time. これは変更可能であるため、この値は、承認の決定には使用できません。Since it is mutable, this value must not be used to make authorization decisions. ただしユーザー名のヒントには使用できます。It can be used for username hints though. この要求を受け取るには、 profile スコープが必要です。The profile scope is required in order to receive this claim.
name StringString トークンのサブジェクトを識別する、人間が判読できる値を提供します。Provides a human-readable value that identifies the subject of the token. この値は、一意であるとは限らず、変更可能であり、表示目的でのみ使用されます。The value is not guaranteed to be unique, it is mutable, and it's designed to be used only for display purposes. この要求を受け取るには、 profile スコープが必要です。The profile scope is required in order to receive this claim.
scp 文字列、スコープのスペース区切りリストString, a space separated list of scopes クライアント アプリケーションが同意を要求し、同意を得た、アプリケーションによって公開されているスコープのセット。The set of scopes exposed by your application for which the client application has requested (and received) consent. アプリでは、これらのスコープがアプリによって公開されている有効なスコープであることを確認し、これらのスコープの値に基づいて承認を決定する必要があります。Your app should verify that these scopes are valid ones exposed by your app, and make authorization decisions based on the value of these scopes. ユーザー トークンにのみ含まれます。Only included for user tokens.
roles 文字列の配列、アクセス許可の一覧Array of strings, a list of permissions 要求元のアプリケーションに呼び出しのアクセス許可が付与されている、アプリケーションまたはユーザーによって公開されているアクセス許可のセット。The set of permissions exposed by your application that the requesting application or user has been given permission to call. アプリケーション トークンでは、これはユーザー スコープの代わりにクライアント資格情報フローで使用されます。For application tokens, this is used during the client-credentials flow in place of user scopes. ユーザー トークンでは、これにはターゲット アプリケーションでユーザーに割り当てられたロールが設定されます。For user tokens this is populated with the roles the user was assigned to on the target application.
wids RoleTemplateID GUID の配列Array of RoleTemplateID GUIDs 管理者ロール ページに存在するロールのセクションから、このユーザーに割り当てられたテナント全体のロールを示します。Denotes the tenant-wide roles assigned to this user, from the section of roles present in the admin roles page. この要求は、アプリケーション マニフェストgroupMembershipClaims プロパティを介して、アプリケーションごとに構成されます。This claim is configured on a per-application basis, through the groupMembershipClaims property of the application manifest. これを "All" または "DirectoryRole" に設定することが必要です。Setting it to "All" or "DirectoryRole" is required. トークンの長さの問題のため、暗黙的フローを介して取得されたトークンには存在しない可能性があります。May not be present in tokens obtained through the implicit flow due to token length concerns.
groups GUID の JSON 配列JSON array of GUIDs サブジェクトのグループ メンバーシップを表すオブジェクト ID です。Provides object IDs that represent the subject's group memberships. これらの値は一意 (「オブジェクト ID」を参照) であり、アクセスの管理 (リソースへのアクセスを承認するなど) に安全に使用できます。These values are unique (see Object ID) and can be safely used for managing access, such as enforcing authorization to access a resource. groups 要求に含まれるグループは、アプリケーション マニフェストgroupMembershipClaims プロパティを使用してアプリケーションごとに構成されます。The groups included in the groups claim are configured on a per-application basis, through the groupMembershipClaims property of the application manifest. 値が null の場合はすべてのグループが除外され、値が ”SecurityGroup” の場合は Active Directory セキュリティ グループのメンバーシップのみが含まれ、値が ”All” の場合はセキュリティ グループと Office 365 配布リストの両方が含まれます。A value of null will exclude all groups, a value of "SecurityGroup" will include only Active Directory Security Group memberships, and a value of "All" will include both Security Groups and Office 365 Distribution Lists.

暗黙的な許可での groups 要求の使用の詳細については、以下の hasgroups 要求を参照してください。See the hasgroups claim below for details on using the groups claim with the implicit grant.
他のフローでは、ユーザーが属するグループの数が上限 (SAML の場合は 150、JWT の場合は 200) を超えた場合、ユーザーのグループのリストを含む AAD Graph エンドポイントを参照する要求ソースに超過要求が追加されます。For other flows, if the number of groups the user is in goes over a limit (150 for SAML, 200 for JWT), then an overage claim will be added to the claim sources pointing at the AAD Graph endpoint containing the list of groups for the user.
hasgroups BooleanBoolean 存在する場合、常に true であり、ユーザーが 1 つ以上のグループに属していることを示します。If present, always true, denoting the user is in at least one group. すべてのグループ要求で URL 長の制限 (現在は 6 以上のグループ) を超えて URI フラグメントが拡張された場合、暗黙的な許可フローの JWT で groups 要求の代わりに使用されます。Used in place of the groups claim for JWTs in implicit grant flows if the full groups claim would extend the URI fragment beyond the URL length limits (currently 6 or more groups). クライアントが Graph を使用して、ユーザーのグループを決定する必要があることを示します (https://graph.windows.net/{tenantID}/users/{userID}/getMemberObjects)。Indicates that the client should use the Graph to determine the user's groups (https://graph.windows.net/{tenantID}/users/{userID}/getMemberObjects).
groups:src1 JSON オブジェクトJSON object 長さは制限されていないが (上記 hasgroups を参照)、トークンには大きすぎるトークン要求の場合、ユーザーのすべてのグループ リストへのリンクが含まれます。For token requests that are not length limited (see hasgroups above) but still too large for the token, a link to the full groups list for the user will be included. SAML では groups 要求の代わりに新しい要求として、JWT では分散要求として使用されます。For JWTs as a distributed claim, for SAML as a new claim in place of the groups claim.

JWT 値の例:Example JWT Value:
"groups":"src1"
"_claim_sources: "src1" : { "endpoint" : "https://graph.windows.net/{tenantID}/users/{userID}/getMemberObjects" }"_claim_sources: "src1" : { "endpoint" : "https://graph.windows.net/{tenantID}/users/{userID}/getMemberObjects" }
sub 文字列、GUIDString, a GUID トークンが情報をアサートするプリンシパルです (アプリのユーザーなど)。The principal about which the token asserts information, such as the user of an app. この値は変更不可で、再割り当ても再利用もできません。This value is immutable and cannot be reassigned or reused. そのため、この値を使用すると、トークンを使用してリソースにアクセスする場合などに安全に承認チェックができます。また、データベース テーブルのキーとして使用することもできます。It can be used to perform authorization checks safely, such as when the token is used to access a resource, and can be used as a key in database tables. サブジェクトは、Azure AD が発行するトークン内に常に存在するため、汎用性のある承認システムでこの値を使用することをお勧めします。Because the subject is always present in the tokens that Azure AD issues, we recommend using this value in a general-purpose authorization system. ただし、サブジェクトはペアワイズ識別子で、特定のアプリケーション ID に一意です。The subject is, however, a pairwise identifier - it is unique to a particular application ID. そのため、1 人のユーザーが 2 つの異なるクライアント ID を使用して 2 つの異なるアプリにサインインすると、そのアプリは、サブジェクト要求に対して 2 つの異なる値を受け取ることになります。Therefore, if a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. この動作が求められているかどうかは、アーキテクチャやプライバシーの要件によって異なります。This may or may not be desired depending on your architecture and privacy requirements. oid 要求 (テナント内のアプリ全体で同じままです) も参照してください。See also the oid claim (which does remain the same across apps within a tenant).
oid 文字列、GUIDString, a GUID Microsoft ID プラットフォーム (ここではユーザー アカウント) におけるオブジェクトの変更不可の識別子です。The immutable identifier for an object in the Microsoft identity platform, in this case, a user account. 承認チェックの安全に実行するとき、また、データベース テーブルのキーとして使用することもできます。It can also be used to perform authorization checks safely and as a key in database tables. この ID によって、複数のアプリケーションでユーザーが一意に識別されます。同じユーザーにサインインする 2 つの異なるアプリケーションは oid 要求で同じ値を受け取ります。This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. そのため、Microsoft Graph などの Microsoft オンライン サービスに対してクエリを実行するときに oid を使用できます。Thus, oid can be used when making queries to Microsoft online services, such as the Microsoft Graph. Microsoft Graph は、この ID を、指定されたユーザー アカウントid プロパティとして返します。The Microsoft Graph will return this ID as the id property for a given user account. oid では複数のアプリがユーザーを関連付けることができるため、この要求を受け取るには、profile スコープが必要です。Because the oid allows multiple apps to correlate users, the profile scope is required in order to receive this claim. 1 人のユーザーが複数のテナントに存在する場合、そのユーザーのオブジェクト ID はテナントごとに異なります。つまり、ユーザーは、同じ資格情報で各アカウントにログインしても、異なるアカウントと見なされます。Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they are considered different accounts, even though the user logs into each account with the same credentials.
tid 文字列、GUIDString, a GUID ユーザーが属している Azure AD テナントを表します。Represents the Azure AD tenant that the user is from. 職場または学校アカウントの場合、GUID はユーザーが属している組織の不変のテナント ID です。For work and school accounts, the GUID is the immutable tenant ID of the organization that the user belongs to. 個人アカウントでは、この値は 9188040d-6c67-4c5b-b112-36a304b66dad です。For personal accounts, the value is 9188040d-6c67-4c5b-b112-36a304b66dad. この要求を受け取るには、 profile スコープが必要です。The profile scope is required in order to receive this claim.
unique_name StringString v1.0 トークンにのみ存在します。Only present in v1.0 tokens. トークンのサブジェクトを識別する、人が判読できる値を提供します。Provides a human readable value that identifies the subject of the token. この値は、テナント内で一意であることが保証されているわけではなく、表示目的でのみ使用する必要があります。This value is not guaranteed to be unique within a tenant and should be used only for display purposes.
uti 不透明な文字列Opaque String Azure がトークンの再検証に使用する内部要求。An internal claim used by Azure to revalidate tokens. リソースでこの要求を使用しないでください。Resources shouldn't use this claim.
rh 不透明な文字列Opaque String Azure がトークンの再検証に使用する内部要求。An internal claim used by Azure to revalidate tokens. リソースでこの要求を使用しないでください。Resources should not use this claim.
ver 文字列、1.0 または 2.0String, either 1.0 or 2.0 アクセス トークンのバージョンを示します。Indicates the version of the access token.

注意

グループ超過要求Groups overage claim

トークンのサイズが HTTP ヘッダー サイズの上限を超えないよう、Azure AD では、グループ要求に含まれるオブジェクト ID の数が制限されます。To ensure that the token size doesn’t exceed HTTP header size limits, Azure AD limits the number of object Ids that it includes in the groups claim. 超過制限 (SAML トークンの場合は 150、JWT トークンの場合は 200) を超えるグループのメンバーにユーザーがなっている場合、Azure AD は、グループ要求をトークンに出力しません。If a user is member of more groups than the overage limit (150 for SAML tokens, 200 for JWT tokens), then Azure AD does not emit the groups claim in the token. 代わりに、Graph API に照会してユーザーのグループ メンバーシップを取得するようアプリケーションに指示する超過要求がトークンに追加されます。Instead, it includes an overage claim in the token that indicates to the application to query the Graph API to retrieve the user’s group membership.

{
  ...
  "_claim_names": {
   "groups": "src1"
    },
    {
  "_claim_sources": {
    "src1": {
        "endpoint":"[Graph Url to get this user's group membership from]"
        }
       }
     }
  ...
 }

超過のシナリオは、App Creation Scripts フォルダーにある BulkCreateGroups.ps1 を使用してテストできます。You can use the BulkCreateGroups.ps1 provided in the App Creation Scripts folder to help test overage scenarios.

v1.0 の基本要求v1.0 basic claims

次の要求は、該当する場合は v1.0 トークンに含まれますが、既定では v2.0 トークンには含まれません。The following claims will be included in v1.0 tokens if applicable, but aren't included in v2.0 tokens by default. v2.0 を使用しており、これらの要求のいずれかが必要な場合は、省略可能な要求を使用してそれらを要求してください。If you're using v2.0 and need one of these claims, request them using optional claims.

要求Claim 形式Format 説明Description
ipaddr StringString ユーザーが認証された IP アドレス。The IP address the user authenticated from.
onprem_sid 文字列 (SID 形式)String, in SID format ユーザーがオンプレミス認証を行った場合、この要求によって SID が提供されます。In cases where the user has an on-premises authentication, this claim provides their SID. レガシ アプリケーションでの承認に onprem_sid を使用できます。You can use onprem_sid for authorization in legacy applications.
pwd_exp int、UNIX タイムスタンプint, a UNIX timestamp ユーザーのパスワードの有効期限を示します。Indicates when the user's password expires.
pwd_url StringString パスワードをリセットするためにユーザーを送信できる URL。A URL where users can be sent to reset their password.
in_corp ブール値boolean クライアントが企業ネットワークからログインしている場合に通知します。Signals if the client is logging in from the corporate network. そうでない場合、この要求は含まれません。If they aren't, the claim isn't included.
nickname stringString ユーザーの追加の名前。姓または名とは別の名前です。An additional name for the user, separate from first or last name.
family_name StringString ユーザー オブジェクトで定義されたユーザーの姓を示します。Provides the last name, surname, or family name of the user as defined on the user object.
given_name StringString ユーザー オブジェクトに設定されたユーザーの名を示します。Provides the first or given name of the user, as set on the user object.
upn stringString ユーザーのユーザー名。The username of the user. 電話番号、電子メール アドレス、または書式なし文字列を指定できます。May be a phone number, email address, or unformatted string. 表示目的でのみ使用し、再認証のシナリオでユーザー名のヒントを提供する必要があります。Should only be used for display purposes and providing username hints in reauthentication scenarios.

amr 要求The amr claim

Microsoft ID は、アプリケーションに関連している可能性のあるさまざまな方法で認証できます。Microsoft identities can authenticate in different ways, which may be relevant to your application. amr 要求は、パスワードと Authenticator アプリの両方を使用した認証用に、複数の項目を格納できる配列 (["mfa", "rsa", "pwd"] など) です。The amr claim is an array that can contain multiple items, such as ["mfa", "rsa", "pwd"], for an authentication that used both a password and the Authenticator app.

Value 説明Description
pwd パスワード認証。ユーザーの Microsoft パスワードまたはアプリのクライアント スークレット。Password authentication, either a user's Microsoft password or an app's client secret.
rsa Microsoft Authenticator アプリを使用した認証など、認証が RSA キーの証明に基づいていたことを示します。Authentication was based on the proof of an RSA key, for example with the Microsoft Authenticator app. これは、認証が、サービスが所有する X509 証明書を使用して自己署名 JWT によって実行された場合に含まれます。This includes if authentication was done by a self-signed JWT with a service owned X509 certificate.
otp 電子メールまたはテキスト メッセージを使用したワンタイム パスコード。One-time passcode using an email or a text message.
fed フェデレーション認証アサーション (JWT や SAML など) が使用されたことを示します。A federated authentication assertion (such as JWT or SAML) was used.
wia Windows 統合認証Windows Integrated Authentication
mfa 多要素認証が使用されたことを示します。Multi-factor authentication was used. この値が存在する場合は、他の認証方法も含まれます。When this is present the other authentication methods will also be included.
ngcmfa mfa と同等です。特定の高度な資格情報の種類のプロビジョニングに使用されます。Equivalent to mfa, used for provisioning of certain advanced credential types.
wiaormfa ユーザーが Windows 資格情報または MFA 資格情報を使用して認証されたことを示します。The user used Windows or an MFA credential to authenticate.
none 認証は実行されませんでした。No authentication was done.

トークンの検証Validating tokens

id_token または access_token を検証するには、アプリはトークンの署名と要求の両方を検証する必要があります。To validate an id_token or an access_token, your app should validate both the token's signature and the claims. アクセス トークンを検証するには、アプリは発行者、対象ユーザー、および署名トークンも検証する必要があります。To validate access tokens, your app should also validate the issuer, the audience, and the signing tokens. これらの検証は、OpenID 探索ドキュメント内の値に対して行ってください。These need to be validated against the values in the OpenID discovery document. たとえば、テナントに依存しないバージョンのドキュメントは https://login.microsoftonline.com/common/.well-known/openid-configuration にあります。For example, the tenant-independent version of the document is located at https://login.microsoftonline.com/common/.well-known/openid-configuration.

Azure AD ミドルウェアにはアクセス トークンを検証するための機能が組み込まれており、選択した言語のサンプルを参照できます。The Azure AD middleware has built-in capabilities for validating access tokens, and you can browse through our samples to find one in the language of your choice. JWT トークンを明示的に検証する方法の詳細については、JWT の手動での検証のサンプルを参照してください。For more information on how to explicitly validate a JWT token, see the manual JWT validation sample.

トークンの検証を簡単に処理する方法を示すライブラリとコード サンプルが用意されています。We provide libraries and code samples that show how to easily handle token validation. 以下の情報は、基になるプロセスを理解することを望む開発者を対象としています。The below information is provided for those who wish to understand the underlying process. JWT の検証に使用できるサードパーティのオープン ソース ライブラリもいくつか存在し、ほぼすべてのプラットフォームと言語に対して少なくとも 1 つのオプションがあります。There are also several third-party open-source libraries available for JWT validation - there is at least one option for almost every platform and language out there. Azure AD 認証ライブラリとコード サンプルの詳細については、v1.0 認証ライブラリに関する記事および v2.0 認証ライブラリに関する記事をご覧ください。For more information about Azure AD authentication libraries and code samples, see v1.0 authentication libraries and v2.0 authentication libraries.

署名の検証Validating the signature

JWT には 3 つのセグメントがあり、 . 文字で区切られています。A JWT contains three segments, which are separated by the . character. 1 番目のセグメントはヘッダー、2 番目は本文、3 番目は署名と呼ばれます。The first segment is known as the header, the second as the body, and the third as the signature. 署名セグメントを使用してトークンの信頼性を検証し、アプリで信頼できることを確認できます。The signature segment can be used to validate the authenticity of the token so that it can be trusted by your app.

Azure AD によって発行されるトークンは、RSA 256 などの業界標準の非対称暗号アルゴリズムを使用して署名されます。Tokens issued by Azure AD are signed using industry standard asymmetric encryption algorithms, such as RSA 256. JWT のヘッダーには、トークンの署名に使用されたキーと暗号方法に関する情報が含まれます。The header of the JWT contains information about the key and encryption method used to sign the token:

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk",
  "kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"
}

alg 要求はトークンへの署名に使用されたアルゴリズムを示し、kid 要求はトークンへの検証に使用された特定の公開キーを示します。The alg claim indicates the algorithm that was used to sign the token, while the kid claim indicates the particular public key that was used to validate the token.

いつでも、Azure AD は公開/秘密キー ペアの特定セットのいずれかを使用して、id_token に署名できます。At any given point in time, Azure AD may sign an id_token using any one of a certain set of public-private key pairs. Azure AD は定期的に使用可能なキー セットをローテーションするので、このキー変更を自動的に処理するようにアプリを作成する必要があります。Azure AD rotates the possible set of keys on a periodic basis, so your app should be written to handle those key changes automatically. Azure AD によって使用される公開キーの更新を確認する適切な頻度は、24 時間間隔です。A reasonable frequency to check for updates to the public keys used by Azure AD is every 24 hours.

署名の検証に必要な署名キー データは、次の場所にある OpenID Connect メタデータのドキュメントを使用して入手できます。You can acquire the signing key data necessary to validate the signature by using the OpenID Connect metadata document located at:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

ヒント

ブラウザーでこの URL を試してみてください!Try this URL in a browser!

このメタデータ ドキュメントの詳細は次のとおりです。This metadata document:

  • OpenID Connect 認証を実行するために必要なさまざまなエンドポイントの場所などの、いくつかの有効な情報を含む JSON オブジェクトです。Is a JSON object containing several useful pieces of information, such as the location of the various endpoints required for doing OpenID Connect authentication.
  • トークンの署名に使用される公開キーのセットの場所を示す jwks_uri が含まれます。Includes a jwks_uri, which gives the location of the set of public keys used to sign tokens. jwks_uri にある JSON Web キー (JWK) には、特定の時点で使用されているすべての公開キー情報が含まれます。The JSON Web Key (JWK) located at the jwks_uri contains all of the public key information in use at that particular moment in time. JWK 形式については RFC 7517 を参照してください。The JWK format is described in RFC 7517. アプリでは、 kid 要求を JWT ヘッダーで使用して、特定のトークンの署名に使用されたこのドキュメント内の公開キーを選択できます。Your app can use the kid claim in the JWT header to select which public key in this document has been used to sign a particular token. その後、正しい公開キーと指定されたアルゴリズムを使用して、署名の検証を実行できます。It can then do signature validation using the correct public key and the indicated algorithm.

注意

V1.0 エンドポイントは x5t および kid の両方の要求を返すのに対して、v2.0 エンドポイントは kid 要求のみで応答します。The v1.0 endpoint returns both the x5t and kid claims, while the v2.0 endpoint responds with only the kid claim. いずれは、kid 要求を利用してトークンを検証することをお勧めします。Going forward, we recommend using the kid claim to validate your token.

署名の検証の実行は、このドキュメントの範囲外です。必要に応じて、それを実行するために役立つオープン ソース ライブラリが多数存在します。Doing signature validation is outside the scope of this document - there are many open source libraries available for helping you do so if necessary. ただし、Microsoft Identity プラットフォームには、標準に対する 1 つのトークン署名拡張であるカスタム署名トークンがあります。However, the Microsoft Identity platform has one token signing extension to the standards - custom signing keys.

claims-mapping 機能を使用した結果としてアプリにカスタム署名キーがある場合は、アプリの署名キー情報 (検証に使用する必要があります) を指す jwks_uri を取得するために、アプリ ID を含む appid クエリ パラメーターを追加する必要があります。If your app has custom signing keys as a result of using the claims-mapping feature, you must append an appid query parameter containing the app ID to get a jwks_uri pointing to your app's signing key information, which should be used for validation. 例: 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-6eba6914391ejwks_uri が含まれます。For example: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e contains a jwks_uri of https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e.

クレーム ベースの承認Claims based authorization

アプリケーションのビジネス ロジックでこの手順を示します。一般的な承認方法を次に示します。Your application's business logic will dictate this step, some common authorization methods are laid out below.

  • scp または roles 要求をチェックして、存在するすべてのスコープが API によって公開されているものに一致することを確認し、クライアントが要求されたアクションを実行することを許可します。Check the scp or roles claim to verify that all present scopes match those exposed by your API, and allow the client to do the requested action.
  • ご自分の API に対して、呼び出し元のクライアントが appid クレームを使った 呼び出しを許可されていることを確認します。Ensure the calling client is allowed to call your API using the appid claim.
  • appidacr を使用して、呼び出し元のクライアントの認証の状態を検証します。これは、パブリック クライアントが API の呼び出しを許可されていない場合は 0 になります。Validate the authentication status of the calling client using appidacr - it shouldn't be 0 if public clients aren't allowed to call your API.
  • 過去の nonce 要求のリストと照合して、トークンが再生されていないことを確認します。Check against a list of past nonce claims to verify the token isn't being replayed.
  • tid が、API の呼び出しを許可されているテナントと一致することを確認します。Check that the tid matches a tenant that is allowed to call your API.
  • acr 要求を使用して、ユーザーが MFA を実行したことを確認します。Use the acr claim to verify the user has performed MFA. これは、条件付きアクセスを使用して適用する必要があります。This should be enforced using Conditional Access.
  • アクセス トークンで roles または groups 要求を要求した場合は、ユーザーが、このアクションの実行を許可されているグループに属していることを確認します。If you've requested the roles or groups claims in the access token, verify that the user is in the group allowed to do this action.
    • 暗黙的フローを使用してトークンを取得した場合、このデータは大きすぎてトークンに収まらないことが多いため、データを Microsoft Graph に照会することが必要になる可能性があります。For tokens retrieved using the implicit flow, you'll likely need to query the Microsoft Graph for this data, as it's often too large to fit in the token.

ユーザー トークンとアプリケーション トークンUser and application tokens

アプリケーションは、ユーザーに代わってトークンを受け取る場合もあれば (通常のフロー)、(クライアント資格情報フローを通じて) アプリケーションから直接受け取る場合もあります。Your application may receive tokens on behalf of a user (the usual flow) or directly from an application (through the client credentials flow). これらのアプリ専用トークンは、この呼び出しがアプリケーションからのものであり、その背後にユーザーがいないことを示します。These app-only tokens indicate that this call is coming from an application and does not have a user backing it. これらのトークンはほぼ同様に処理されますが、違いがいくつかあります。These tokens are handled largely the same, with some differences:

  • アプリ専用トークンには scp 要求は含まれず、代わりに roles 要求が含まれることがあります。App-only tokens will not have a scp claim, and may instead have a roles claim. これに、(委任されたアクセス許可ではなく) アプリケーションのアクセス許可が記録されます。This is where application permission (as opposed to delegated permissions) will be recorded. 委任されたアクセス許可とアプリケーションのアクセス許可の詳細については、v1.0 および v2.0 のアクセス許可と同意を参照してください。For more information about delegated and application permissions, see permission and consent in v1.0 and v2.0.
  • 多くの人間固有の要求 (nameupn など) はありません。Many human-specific claims will be missing, such as name or upn.
  • sub および oid 要求は同じになります。The sub and oid claims will be the same.

トークンの失効Token revocation

更新トークンは、さまざまな理由でいつでも無効にしたり、取り消したりできます。Refresh tokens can be invalidated or revoked at any time, for different reasons. これらはタイムアウトと失効の 2 つに大きく分けることができます。These fall into two main categories: timeouts and revocations.

トークンのタイムアウトToken timeouts

  • MaxInactiveTime:更新トークンが MaxInactiveTime で指示された時間内に使用されなかった場合、更新トークンは無効になります。MaxInactiveTime: If the refresh token hasn't been used within the time dictated by the MaxInactiveTime, the Refresh Token will no longer be valid.
  • MaxSessionAge:MaxAgeSessionMultiFactor または MaxAgeSessionSingleFactor が既定値 (Until-revoked) 以外に設定されている場合、MaxAgeSession* に設定された時間が経過すると、再認証が必要になります。MaxSessionAge: If MaxAgeSessionMultiFactor or MaxAgeSessionSingleFactor have been set to something other than their default (Until-revoked), then reauthentication will be required after the time set in the MaxAgeSession* elapses.
  • 次に例を示します。Examples:
    • テナントの MaxInactiveTime が 5 日で、ユーザーが 1 週間の休暇を取った場合、7 日間にわたり Azure AD はユーザーからの新しいトークン要求を認識しません。The tenant has a MaxInactiveTime of five days, and the user went on vacation for a week, and so Azure AD hasn't seen a new token request from the user in 7 days. ユーザーが次に新しいトークンを要求するとき、更新トークンが失効していることがわかります。資格情報を再び入力する必要があります。The next time the user requests a new token, they'll find their Refresh Token has been revoked, and they must enter their credentials again.
    • 機密性の高いアプリケーションの MaxAgeSessionSingleFactor は 1 日に設定されています。A sensitive application has a MaxAgeSessionSingleFactor of one day. ユーザーが月曜日にログインし、次に火曜日 (25 時間が経過した後) にログインした場合は、再認証が必要になります。If a user logs in on Monday, and on Tuesday (after 25 hours have elapsed), they'll be required to reauthenticate.

無効化Revocation

パスワードに基づくクッキーPassword-based cookie パスワードに基づくトークンPassword-based token パスワードに基づかないクッキーNon-password-based cookie パスワードに基づかないトークンNon-password-based token 機密のクライアントのトークンConfidential client token
パスワードが期限切れPassword expires 存続Stays alive 存続Stays alive 存続Stays alive 存続Stays alive 存続Stays alive
ユーザーによるパスワードの変更Password changed by user 取り消しRevoked 取り消しRevoked 存続Stays alive 存続Stays alive 存続Stays alive
ユーザーがSSPRであるUser does SSPR 取り消しRevoked 取り消しRevoked 存続Stays alive 存続Stays alive 存続Stays alive
管理者によるパスワードのリセットAdmin resets password 取り消しRevoked 取り消しRevoked 存続Stays alive 存続Stays alive 存続Stays alive
ユーザーが PowerShellによって、更新トークンを無効にするUser revokes their refresh tokens via PowerShell 取り消しRevoked 取り消しRevoked 取り消しRevoked 取り消しRevoked 取り消しRevoked
管理者が PowerShellによって、テナントのすべての更新トークンを無効にするAdmin revokes all refresh tokens for the tenant via PowerShell 取り消しRevoked 取り消しRevoked 取り消しRevoked 取り消しRevoked 取り消しRevoked
Web でのシングル サインアウトSingle sign-out on web 取り消しRevoked 存続Stays alive 取り消しRevoked 存続Stays alive 存続Stays alive

注意

「パスワード基づかない」ログインは、ユーザーがそれを得るために、パスワードをタイプしなかった場合です。A "Non-password based" login is one where the user didn't type in a password to get it. たとえば、Windows Hello、FIDO2 キー、または PIN で自分の顔を使用する場合です。For example, using your face with Windows Hello, a FIDO2 key, or a PIN.

Windows 10 のプライマリ更新トークン (PRT) は、資格情報に基づいて分離されます。Primary Refresh Tokens (PRT) on Windows 10 are segregated based on the credential. たとえば、Windows Hello とパスワードにはそれぞれ独立した PRT があります。For example, Windows Hello and password have their respective PRTs, isolated from one another. ユーザーが Hello の資格情報 (PIN または生体認証) を使用してサインインし、パスワードを変更すると、以前に取得したパスワードベースの PRT が取り消されます。When a user signs-in with a Hello credential (PIN or biometrics) and then changes the password, the password based PRT obtained previously will be revoked. パスワードを使用して再度サインインすると、古い PRT が無効になり、新しい PRT が要求されます。Signing back in with a password invalidates the old PRT and requests a new one.

更新トークンは、新しいアクセス トークンや更新トークンのフェッチに使用されるときに無効になる、または取り消されることはありません。Refresh tokens aren't invalidated or revoked when used to fetch a new access token and refresh token.

次の手順Next steps