認証の新機能

Microsoft は、セキュリティ、使いやすさ、標準へのコンプライアンスを向上させるために、Microsoft ID プラットフォームの機能を定期的に追加および変更します。

特に記載がない限り、ここで説明する変更は、指定された変更の有効日の後に登録されたアプリケーションにのみ適用されます。

この記事を定期的に調べて、以下の内容を確認してください。

• 既知の問題と修正
• Protocol changes
• Deprecated functionality

August 2024

フェデレーション ID 資格情報で大文字と小文字が区別される照合が使用されるようになりました

Effective date: September 2024

Protocol impacted: Workload identity federation

Change

以前は、外部 IdP によって Microsoft Entra ID に送信されたトークンに含まれる値とissuer、フェデレーション ID 資格情報 (FIC) subjectaudience、および値を照合issuersubjectするときに、大文字とaudience小文字を区別しない照合が使用されていました。 よりきめ細かな制御を顧客に提供するために、大文字と小文字を区別した照合の適用に切り替えています。

Invalid example:

• トークンの件名: repo:contoso/contoso-org:ref:refs/heads/main
• FIC の件名: repo:Contoso/Contoso-Org:ref:refs/heads/main

これら 2 つのサブジェクト値は大文字と小文字が区別されないので、検証は失敗します。 同じメカニズムが適用 issuer され、 audience 検証されます。

この変更は、最初に後に作成された August 14th, 2024アプリケーションまたはマネージド ID に適用されます。 非アクティブなアプリケーションまたはマネージド ID は、その期間August 1st, 2024August 31st, 2024の間にアプリケーションまたはマネージド ID によって行われたワークロード ID フェデレーション要求がゼロであることによって決定され、開始時September 27th, 2024に大文字と小文字を区別する照合を使用する必要があります。 アクティブなアプリケーションの場合、大文字と小文字が区別される照合は後日伝達されます。

大文字と小文字の区別によるエラーをより適切に強調表示するために、AADSTS700213のエラー メッセージを改良しています。 次に、次の状態になります。

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

プレースホルダー '{subject}' は、外部 IdP から Microsoft Entra ID に送信されるトークンに含まれるサブジェクト要求の値を提供します。 このエラー テンプレートは、大文字と小文字を区別しないエラーの周囲 issuer と audience 検証にも使用されます。 このエラーが発生した場合は、エラーに対応するフェデレーション ID 資格情報、またはissuerエラーにsubjectaudience一覧表示されているフェデレーション ID 資格情報を見つけ、対応する値が大文字と小文字を区別する観点から同等であることを確認する必要があります。 不一致がある場合は、FIC の現在 issuerの値、 subjectまたは audience 値を、エラー メッセージに issuer含まれていた 、 subjectまたは audience 値に置き換える必要があります。

June 2024

アプリケーションは 1 つのディレクトリに登録する必要がある

Effective date: June 2024

Endpoints impacted: v2.0 and v1.0

Protocol impacted: All flows

Change

以前は、Microsoft Entra アプリ登録エクスペリエンスを使用してアプリケーションを登録するときに、ユーザーが個人の Microsoft アカウント (MSA) でサインインした場合、アプリケーションを自分の個人用アカウントにのみ関連付ける選択をできました。 つまり、アプリケーションはディレクトリ ("テナント" または "組織" とも呼ばれます) に関連付けられていないか、または含まれません。 ただし、2024 年 6 月以降は、すべてのアプリケーションを 1 つのディレクトリに登録する必要があります。 これは、既存のディレクトリ、または個人の Microsoft アカウント ユーザーが Microsoft Entra アプリケーションやその他の Microsoft リソースを格納するために作成する新しいディレクトリです。 ユーザーは、Microsoft 365 開発者プログラムに参加するか、Azure にサインアップすることで、この目的に使用する新しいディレクトリを簡単に作成できます。

アプリケーションを個人用アカウントに関連付けるのではなく、ディレクトリに登録すると、さまざまな利点があります。 These include:

• Applications registered in a directory have more features available to them, such as the ability to add more than one owner to the app, and the ability to publisher verify the app.
• アプリケーションは、開発者が使用する他の Microsoft リソース (Azure リソースなど) と同じ場所にあります。
• アプリケーションは、回復性の向上の利点を受け取ります。

これは、個人用アカウントにのみ関連付けられている既存のアプリケーションを含め、既存のアプリケーションには影響しません。 新しいアプリケーションを登録する機能のみが影響を受けます。

October 2023

更新された RemoteConnect UX プロンプト

Effective date: October 2023

Endpoints impacted: v2.0 and v1.0

Protocol impacted: RemoteConnect

RemoteConnect は、プライマリ更新トークンなど、Microsoft 認証ブローカーと Microsoft Intune 関連のシナリオに使用されるクロスデバイス フローです。 フィッシング攻撃を防ぐために、RemoteConnect フローは更新された UX 言語を受け取り、フローの正常な完了時にリモート デバイス (フローを開始したデバイス) が組織で使用されるすべてのアプリケーションにアクセスできることを呼び出しています。

表示されるプロンプトは次のようになります。

June 2023

未確認のドメイン所有者を持つ電子メール要求の省略

Effective date: June 2023

Endpoints impacted: v2.0 and v1.0

Change

For multi-tenant applications, emails that aren't ___domain-owner verified are omitted by default when the optional email claim is requested in a token payload.

次の場合、電子メールはドメイン所有者を確認済みと見なされます。

1. ユーザー アカウントが存在するテナントにドメインが属しており、テナント管理者によってドメインの確認が行われた。
2. Microsoft アカウント (MSA) からの電子メールである。
3. Google アカウントからの電子メールである。
4. ワンタイム パスコード (OTP) フローを使用した認証に使用された電子メールである。

また、Facebook アカウントと SAML/WS-Fed アカウントには、検証済みドメインがないことに注意する必要があります。

May 2023

Power BI 管理者ロールの名称は Fabric 管理者に変更されます。

Effective date: June 2023

Endpoints impacted:

• roleDefinitions の一覧表示 - Microsoft Graph v1.0
• directoryRoles の一覧表示 - Microsoft Graph v1.0

Change

Power BI 管理者ロールの名前がファブリック管理者に変更されました。

2023 年 5 月 23 日、Microsoft は Microsoft Fabric を発表しました。Data Factory によるデータ統合エクスペリエンス、Synapse によるデータ エンジニアリング、データ ウェアハウス、データ サイエンス、リアルタイム分析エクスペリエンス、Power BI を使ったビジネス インテリジェンス (BI) を備えており、これらすべてがレイク中心の SaaS ソリューションでホストされています。 これらのエクスペリエンス用のテナントと容量の管理は、Fabric 管理ポータル (旧称は Power BI 管理ポータル) に一元化されています。

2023 年 6 月以降、このロールのスコープと責任の変化に合わせて、Power BI 管理者ロールの名前がファブリック管理者に変更されます。 Microsoft Entra ID、Microsoft Graph API、Microsoft 365、GDAP を含むすべてのアプリケーションには、今後数週間で新しいロール名が反映される予定です。

アプリケーション コードやスクリプトでは、ロール名や表示名に基づいて決定を下さないように注意してください。

December 2021

AD FS ユーザーには、正しいユーザーがサインインしていることを確認するための追加のログイン プロンプトが表示されます。

Effective date: December 2021

Endpoints impacted: Integrated Windows Authentication

Protocol impacted: Integrated Windows Authentication

Change

現在、ユーザーは認証のために AD FS に送られると、AD FS とのセッションが既に存在するアカウントに自動的にサインインさせられます。 この自動サインインは、ユーザーが別のユーザー アカウントにサインインするつもりであっても発生します。 この誤ったサインインの発生頻度を減らすために、12 月より、Windows の Web アカウント マネージャーがサインイン時にサインインに特定のユーザーが必要であることを示すパラメーター prompt=login を Microsoft Entra ID に提供した場合、Microsoft Entra ID は AD FS にパラメーター login_hint を送信するようになります。

上記の要件が満たされている場合 (サインインに向けてユーザーを Microsoft Entra ID に送信するために WAM が使用され、login_hint が含まれており、ユーザーのドメインの AD FS インスタンスが prompt=login をサポートしている場合)、ユーザーは自動的にサインインされません。代わりに AD FS にサインインし続けるユーザー名を指定する必要があります。 既存の AD FS セッションにサインインする場合は、ログイン プロンプトの下に表示される [現在のユーザーとして続行] オプションを選択できます。 それ以外の場合は、サインインに使用するユーザー名で続行できます。

この変更は、2021 年 12 月、数週間にかけて展開されます。 次の場合、サインインの動作は変更されません。

• IWA を直接使用するアプリケーション
• OAuth を使用するアプリケーション
• AD FS インスタンスにフェデレーションされていないドメイン

October 2021

対話型認証中にエラー 50105 がinteraction_required返されない問題を修正しました

Effective date: October 2021

Endpoints impacted: v2.0 and v1.0

Protocol impacted: All user flows for apps requiring user assignment

Change

割り当てられていないユーザーが、管理者がユーザー割り当てを要求するとマークしたアプリにサインインしようとすると、エラー 50105 (現在の指定) が生成されます。 これは一般的なアクセス制御パターンであり、ユーザーは多くの場合、アクセスのブロックを解除するために割り当てを要求する管理者を見つける必要があります。 エラーには、interaction_requiredエラー応答を正しく処理する適切にコード化されたアプリケーションで無限ループを引き起こすバグが存在しました。 interaction_required はアプリに対話型認証を実行するよう指示しますが、それを実行した後にも、Microsoft Entra ID が引き続き interaction_required エラー応答を返すようになっていました。

エラー シナリオが更新されたので、非対話型認証 (prompt=noneはUX を非表示にする場合) に、interaction_requiredエラー応答を使用して対話型認証を実行するようにアプリに指示されます。 その後の対話型認証では、Microsoft Entra ID がユーザーを保持し、エラーメッセージを直接表示して、ループが発生しないようにします。

アプリケーション コードでは、AADSTS50105 のようなエラー コード文字列に基づいて決定を行うべきではないことに注意してください。 代わりに、エラー処理に関するガイダンスに従い、応答の標準 フィールドにある interaction_required や login_required のようなerrorを使用します。 他の応答フィールドは、問題のトラブルシューティングを行う人間による使用のみを目的としています。

エラー検索サービス https://login.microsoftonline.com/error?code=50105 では、50105 エラーの現在のテキストと詳細を確認できます。

シングル テナント アプリケーションの AppId URI には、既定のスキームまたは検証済みドメインを使用する必要があります

Effective date: October 2021

Endpoints impacted: v2.0 and v1.0

Protocol impacted: All flows

Change

シングル テナント アプリケーションの場合、AppId URI を追加または更新すると、HTTPS スキームの URI のドメインが顧客テナントの検証済みドメイン リストに含まれるか、または Microsoft Entra ID によって提供される既定のスキーム (api://{appId}) がその値で使われているかが検証されます。 これにより、ドメインが検証済みドメイン リストに含まれない場合、または値で既定のスキームが使用されていない場合は、アプリケーションで AppID URI を追加できないおそれがあります。 検証済みドメインの詳細については、カスタム ドメインのドキュメントを参照してください。

この変更は、AppID URI で未検証のドメインが使用されている既存のアプリケーションには影響しません。 検証が行われるのは、新しいアプリケーションの場合、または既存のアプリケーションで識別子 URI が更新されるか、新しいものが identifierUri コレクションに追加されるときだけです。 新しい制限は、2021 年 10 月 15 日より後にアプリの identifierUris コレクションに追加された URI にのみ適用されます。 2021 年 10 月 15 日に制限が有効になった時点でアプリケーションの identifierUris コレクションに既に存在している AppId URI は、そのコレクションに新しい URI が追加されても引き続き機能します。

検証チェックで要求に問題があった場合、作成および更新用のアプリケーション API からは HostNameNotOnVerifiedDomain を示す 400 badrequest がクライアントに返されます。

次の API および HTTP スキームベースのアプリケーション ID URI 形式がサポートされます。 表の後の一覧の説明に従って、プレースホルダーの値を置き換えてください。

• <appId> - アプリケーション オブジェクトのアプリケーション ID (appId) プロパティ。
• <string> - ホストまたは API パスのセグメントの文字列値。
• <tenantId> - Azure 内のテナントを表すために Azure によって生成された GUID。
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com。<tenantInitialDomain> は、テナント作成時にテナント作成者が指定した初期ドメイン名です。
• <verifiedCustomDomain> - Microsoft Entra テナント用に構成された検証済みのカスタム ドメイン。

August 2021

条件付きアクセスは、明示的に要求されたスコープに対してのみトリガーされる

Effective date: August 2021, with gradual rollout starting in April.

Endpoints impacted: v2.0

Protocol impacted: All flows using dynamic consent

現在、動的な同意が使用されているアプリケーションでは、名前を指定して scope パラメーターで要求されなかった場合でも、同意があるすべてのアクセス許可が付与されます。 たとえば、user.read のみが要求されているが、files.read に対する同意も含まれているアプリでは、files.read のために割り当てられている条件付きアクセス要件が強制的に渡される場合があります。

不要な条件付きアクセスのプロンプト数を減らすため、Microsoft Entra ID では、スコープがアプリケーションに提供される方法を変更し、明示的に要求されたスコープのみによって条件付きアクセスがトリガーされるようにします。 Applications relying on Microsoft Entra ID's previous behavior of including all scopes in the token--whether requested or not--may break due to missing scopes.

今後、アプリでは、混合したアクセス許可 (要求されたトークンと、同意はあるが、条件付きアクセスのプロンプトが必要ないもの) が含まれたアクセス トークンを受け取ります。 トークンに対するアクセスのスコープは、トークン応答の scope パラメーターに反映されます。

この変更は、この動作に対して、依存関係が確認されたものを除く、すべてのアプリを対象に行われます。 それらが追加の条件付きアクセス プロンプトに依存している可能性があるため、この変更から除外されている場合、開発者はアウトリーチを受け取ります。

Examples

アプリには、user.read、files.readwrite、および tasks.read に対する同意があります。 files.readwrite には、条件付きアクセス ポリシーが適用されていますが、他の 2 つには適用されていません。 アプリで scope=user.read に対するトークン要求が行われ、現在サインインしているユーザーが条件付きアクセス ポリシーを渡していない場合、結果として得られるトークンは user.read と tasks.read のアクセス許可を対象としたものになります。 tasks.read が含まれている理由は、それに対する同意がアプリにあり、かつ条件付きアクセス ポリシーを適用する必要がないからです。

次に、アプリで scope=files.readwrite が要求されると、テナントによって要求される条件付きアクセスがトリガーされ、条件付きアクセス ポリシーを満たすことができる対話型認証プロンプトの表示がアプリに対して強制されます。 返されるトークンには、3 つすべてのスコープが含まれます。

次に、アプリがその 3 つのスコープのいずれか (たとえば、scope=tasks.read) に対して最後の要求を行うと、Microsoft Entra ID では、ユーザーが files.readwrite に必要な条件付きアクセス ポリシーを既に完了していることを確認し、3 つすべてのアクセス許可が含まれたトークンを再び発行します。

June 2021

デバイス コード フロー UX にアプリの確認プロンプトが含まれるようになります

Effective date: June 2021.

Endpoints impacted: v2.0 and v1.0

Protocol impacted: The device code flow

フィッシング攻撃を防ぐために、デバイス コード フローに、ユーザーが予想するアプリにサインインしていることを検証するプロンプトが含まれるようになりました。

表示されるプロンプトは次のように表示されます。

May 2020

バグ修正: Microsoft Entra ID が状態パラメーターを 2 回 URL エンコードしなくなります

Effective date: May 2021

Endpoints impacted: v1.0 and v2.0

Protocol impacted: All flows that visit the /authorize endpoint (implicit flow and authorization code flow)

Microsoft Entra 承認応答でバグが見つかり、修正されました。 認証の /authorize 段階では、応答に要求からの state パラメーターが含まれます。これにより、アプリの状態が維持され、CSRF 攻撃を防ぐことができます。 state パラメーターがエンコードされた応答に、このパラメーターを挿入する前に、Microsoft Entra ID により、誤ってこのパラメーターがもう一度 URL エンコードされます。 これにより、アプリケーションが Microsoft Entra ID からの応答を誤って拒否する可能性があります。

Microsoft Entra ID によるこのパラメーターのダブルエンコードがなくなり、アプリで結果を正しく解析できるようになります。 この変更はすべてのアプリケーションに対して行われます。

Azure Government エンドポイントの変更

Effective date: May 5, 2020 (Finishing June 2020)

Endpoints impacted: All

Protocol impacted: All flows

2018 年 6 月 1 日、Azure Government の公式 Microsoft Entra Authority が https://login-us.microsoftonline.com から https://login.microsoftonline.us に変更されました。 この変更は、Azure Government Microsoft Entra ID でもサービスが提供される Microsoft 365 GCC High および DoD にも適用されます。 米国政府テナント内でアプリケーションを所有している場合は、.us エンドポイントでユーザーをサインインさせるようにアプリケーションを更新する必要があります。

2020 年 5 月 5 日に、Microsoft Entra ID でエンドポイントの変更の適用が開始され、政府ユーザーはパブリック エンドポイント (microsoftonline.com) を使用して米国政府テナントでホストされているアプリにサインインできなくなります。 影響を受けるアプリでは、AADSTS900439 - USGClientNotSupportedOnPublicEndpoint エラーが表示されるようになります。 このエラーは、アプリがパブリック クラウド エンドポイントで米国政府ユーザーのサインインを試みていることを示します。 アプリがパブリック クラウド テナント内にあり、米国政府ユーザーのサポートを意図している場合は、それらのユーザーを明示的にサポートするようにアプリを更新する必要があります。 これには、米国政府機関向けクラウドで新しいアプリの登録を作成することが必要になる場合があります。

この変更の適用は、米国政府のクラウドからアプリケーションにサインインするユーザーの頻度に基づいて、段階的なロールアウトを使用して行われます。米国政府ユーザーがサインインする頻度の少ないアプリは最初に適用され、米国政府ユーザーが頻繁に使用するアプリは最後に適用されます。 2020 年 6 月には、すべてのアプリで適用が完了するものと思われます。

詳細については、この移行に関する Azure Government ブログ記事を参照してください。

March 2020

ユーザーのパスワードは、256 文字に制限されます。

Effective date: March 13, 2020

Endpoints impacted: All

Protocol impacted: All user flows.

Microsoft Entra ID に直接サインインし、パスワードが 256 文字を超えるユーザー (AD FS のようなフェデレーション IDP ではない) は、サインインする前にパスワードの変更を求められます。 管理者は、ユーザーのパスワード リセットを支援するように要求される場合があります。

サインイン ログのエラーは、AADSTS 50052: InvalidPasswordExceedsMaxLength とほぼ同じです。

メッセージ: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Remediation:

パスワードが許可されている最大長を超えているため、ユーザーはログインできません。 パスワードをリセットするには、管理者に連絡する必要があります。 テナントで SSPR が有効になっている場合は、[パスワードを忘れた場合] のリンクを使用してパスワードをリセットできます。

February 2020

ログイン エンドポイントからのすべての HTTP リダイレクトに空のフラグメントが追加されます。

Effective date: February 8, 2020

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: OAuth and OIDC flows that use response_type=query - this covers the authorization code flow in some cases, and the implicit flow.

When an authentication response is sent from login.microsoftonline.com to an application via HTTP redirect, the service will append an empty fragment to the reply URL. これにより、ブラウザーで認証要求内の既存のフラグメントがすべて消去され、リダイレクト攻撃のクラスを防止できます。 アプリはこの動作に依存しないようにしてください。

August 2019

POST フォームのセマンティクスがより厳密に適用され、スペースおよび引用符は無視されます

Effective date: September 2, 2019

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: Anywhere POST is used (client credentials, authorization code redemption, ROPC, OBO, and refresh token redemption)

2019 年 9 月 2 日の週から、POST メソッドを使用する認証要求は、より厳格な HTTP 標準を使用して検証されます。 具体的には、スペースと二重引用符 (") が要求フォームの値から削除されなくなります。 これらの変更によって、既存のクライアントが中断されることはなく、Microsoft Entra ID に送信された要求は毎回確実に処理されます。 今後 (上記参照)、重複するパラメーターを拒否し、要求内の BOM を無視することをさらに計画しています。

Example:

現在、?e= "f"&g=h は ?e=f&g=h と同じように解析されるため、e == f となります。 この変更により、これは e == "f" と解析されるようになりました。これは有効な引数である可能性が低く、要求は失敗します。

July 2019

シングルテナント アプリケーションのアプリ専用トークンは、クライアント アプリがリソース テナントに存在する場合にのみ発行される

Effective date: July 26, 2019

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: Client Credentials (app-only tokens)

(クライアント資格情報の付与による) アプリ専用トークンの発行方法を変更するセキュリティの変更が、2019 年 7 月 26 日に有効になりました。 以前は、テナント内の存在またはそのアプリケーションに対して同意されているロールに関係なく、アプリケーションではトークンを取得して他のアプリを呼び出すことができました。 この動作が更新され、シングルテナント (既定) に設定されているリソース (Web API と呼ばれることもあります) の場合、クライアント アプリケーションはリソース テナント内に存在する必要があります。 クライアントと API の間の既存の同意は依然として必須ではなく、アプリでは、roles 要求が存在し、API に必要な値が含まれていることを確認するために、独自の承認チェックを実行する必要があります。

現在、このシナリオのエラー メッセージは次のようになっています。

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

この問題を解決するには、管理者の同意エクスペリエンスを使ってテナントにクライアント アプリケーション サービス プリンシパルを作成するか、手動で作成します。 この要件により、テナントによってアプリケーションにテナント内で動作するアクセス許可が付与されていることが確認されます。

Example request

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0&... この例では、リソース テナント (機関) は contoso.com、リソース アプリは Contoso テナントに対する gateway.contoso.com/api という名前のシングルテナント アプリ、クライアント アプリは ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0 です。 クライアント アプリが Contoso.com 内にサービス プリンシパルを持っている場合は、この要求を続行できます。 そうでない場合、要求は上記のエラーで失敗します。

ただし、Contoso ゲートウェイ アプリがマルチテナント アプリケーションの場合は、クライアント アプリのサービス プリンシパルが Contoso.com 内にあるかどうかに関係なく、要求は続行されます。

リダイレクト URI にクエリ文字列パラメーターを含めることができるようになった

Effective date: July 22, 2019

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: All flows

Per RFC 6749, Microsoft Entra applications can now register and use redirect (reply) URIs with static query parameters (such as https://contoso.com/oauth2?idp=microsoft) for OAuth 2.0 requests. 動的リダイレクト URI は、セキュリティ上のリスクがあり、認証要求全体で状態情報を保持するために使用できないため、引き続き許可されません。そのためには、state パラメーターを使用します。

静的クエリ パラメーターは、リダイレクト URI の他の部分と同様に、リダイレクト URI の文字列照合の対象になります。URI でデコードされたリダイレクト URI に一致する文字列が登録されていない場合、要求は拒否されます。 アプリの登録で URI が見つかった場合は、静的クエリ パラメーターを含む文字列全体が、ユーザーをリダイレクトするために使われます。

現時点 (2019 年 7 月末) では、Azure portal のアプリ登録 UX では、クエリ パラメーターが引き続きブロックされます。 ただし、アプリケーション マニフェストを手動で編集して、クエリ パラメーターを追加し、アプリでこれをテストすることができます。

March 2019

クライアントのループ処理が中断されます

Effective date: March 25, 2019

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: All flows

クライアント アプリケーションが誤動作し、短期間に数百の同じログイン要求を発行する場合があります。 これらの要求は成功する場合もしない場合もありますが、そのすべてがユーザー エクスペリエンスの低下や IDP のワークロードの増加につながるため、すべてのユーザーの待ち時間が長くなり、IDP の可用性が低下します。 これらのアプリケーションは通常の使用の範囲外で動作しており、正しく動作するように更新する必要があります。

重複した要求を複数回発行するクライアントには invalid_grant エラー: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request が送信されます。

ほとんどのクライアントは、動作を変更してこのエラーを回避する必要はありません。 正しく構成されていない (トークンのキャッシュを使用していない、または既にプロンプト ループを示している) クライアントのみがこのエラーの影響を受けます。 クライアントは、次の要因に対して (Cookie 経由で) ローカルにインスタンスごとに追跡されます。

• ユーザー ヒント (存在する場合)

• 要求されているスコープまたはリソース

• Client ID

• Redirect URI

• 応答の種類とモード

短期間 (5 分) に複数の (15 を超える) 要求を発行しているアプリは、ループ処理していることを示す invalid_grant エラーを受信します。 要求されているトークンには十分に長い有効期間 (最小 10 分、既定では 60 分) があるため、この期間にわたって繰り返される要求は必要ありません。

すべてのアプリが、確認なしでトークンを要求するのではなく、対話型プロンプトを示すことによって invalid_grant を処理する必要があります。 このエラーを回避するために、クライアントは、受信したトークンを正しくキャッシュしていることを確認する必要があります。

October 2018

認証コードを再利用できなくなりました

Effective date: November 15, 2018

Endpoints impacted: Both v1.0 and v2.0

Protocol impacted: Code flow

2018 年 11 月 15 日以降、Microsoft Entra ID では、以前使用されていた、アプリの認証コードの受け入れが停止されます。 このセキュリティの変更により、Microsoft Entra ID と OAuth の仕様が一致するようになります。この変更は、v1 と v2 両方のエンドポイントに適用されます。

お使いのアプリで承認コードを再利用して複数のリソースに対するトークンを取得している場合は、コードを使用して更新トークンを取得した後、その更新トークンを使用して他のリソース用のトークンを追加取得することお勧めします。 承認コードは 1 回しか使用できませんが、更新トークンは複数のリソースで複数回使用できます。 OAuth コード フローの使用時に新しいアプリで認証コードを再利用しようとすると、invalid_grant エラーが発生します。

更新トークンについて詳しくは、「アクセス トークンの更新」をご覧ください。 MSAL を使用している場合、これはライブラリによって自動的に処理されます。 AcquireTokenByAuthorizationCodeAsync の 2 番目のインスタンスを AcquireTokenSilentAsyncに置き換えます。

May 2018

ID トークンは、OBO フローに使用できません

Date: May 1, 2018

Endpoints impacted: Both v1.0 and v2.0

Protocols impacted: Implicit flow and on-behalf-of flow

2018 年 5 月 1 日以降、id_tokens は新しいアプリケーションの OBO フローでアサーションとして使用できません。 代わりに、アクセス トークンを使用して、同じアプリケーションのクライアントと中間層の間でも、API のセキュリティを確保する必要があります。 2018 年 5 月 1 日より前に登録されたアプリは、引き続き動作し、id_tokens をアクセス トークンに交換することができますが、このパターンはベスト プラクティスとは見なされません。

この変更を回避するには、次の操作を行います。

1. 1 つ以上のスコープを使用して、アプリケーション用の Web API を作成します。 この明示的なエントリ ポイントにより、きめ細かな制御とセキュリティが可能になります。
2. In your app's manifest, in the Azure portal or the app registration portal, ensure that the app is allowed to issue access tokens via the implicit flow. これは oauth2AllowImplicitFlow キーによって制御されます。
3. クライアント アプリケーションで response_type=id_token を使用して id_token を要求した場合、上記で作成した Web API に対してもアクセス トークン (response_type=token) を要求します。 したがって、v2.0 エンドポイントを使用する場合、scope パラメータは api://GUID/SCOPE と同様のものになります。 v1.0 エンドポイントでは、resource パラメータを Web API のアプリ URI にする必要があります。
4. このアクセストークンを、id_token の代わりに、中間層に渡します。