認証の新機能
Microsoft は、セキュリティ、使いやすさ、標準へのコンプライアンスを向上させるために、Microsoft ID プラットフォームの機能を定期的に追加および変更します。
特に記載がない限り、ここで説明する変更は、指定された変更の有効日の後に登録されたアプリケーションにのみ適用されます。
この記事を定期的に調べて、以下の内容を確認してください。
- 既知の問題と修正
- プロトコルの変更
- 非推奨の機能
ヒント
このページの更新に関する通知を受け取るには、この URL を RSS フィード リーダーに追加してください。https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us
2023 年 10 月
更新された RemoteConnect UX プロンプト
発効日: 2023 年 10 月
影響を受けるエンドポイント: v2.0 および v1.0
影響を受けるプロトコル: RemoteConnect
RemoteConnect は、プライマリ更新トークンなど、Microsoft 認証ブローカーと Microsoft Intune 関連のシナリオに使用されるクロスデバイス フローです。 フィッシング攻撃を防ぐため、RemoteConnect フローは、フローが正常に完了するとリモート デバイス (フローを開始したデバイス) が組織によって使用されているすべてのアプリケーションにアクセスできるようになることを注意するため更新された UX 言語を受け取ることになります。
表示されるプロンプトは次のようになります。
2023 年 6 月
未確認のドメイン所有者を持つ電子メール要求の省略
発効日: 2023 年 6 月
影響を受けるエンドポイント: v2.0 および v1.0
変更
マルチテナント アプリケーションの場合、トークン ペイロードで省略可能な email 要求が要求されると、ドメイン所有者が確認されていない電子メールは既定で省略されます。
次の場合、電子メールはドメイン所有者を確認済みと見なされます。
- ユーザー アカウントが存在するテナントにドメインが属しており、テナント管理者によってドメインの確認が行われた。
- Microsoft アカウント (MSA) からの電子メールである。
- Google アカウントからの電子メールである。
- ワンタイム パスコード (OTP) フローを使用した認証に使用された電子メールである。
また、Facebook アカウントと SAML/WS-Fed アカウントには、確認済みドメインがないことを確認する必要があります。
2023 年 5 月
Power BI 管理者ロールの名称は Fabric 管理者に変更されます。
発効日: 2023 年 6 月
影響を受けるエンドポイント:
- roleDefinitions の一覧表示 - Microsoft Graph v1.0
- directoryRoles の一覧表示 - Microsoft Graph v1.0
変更
Power BI 管理者ロールの名称は Fabric 管理者に変更されます。
2023 年 5 月 23 日、Microsoft は Microsoft Fabric を発表しました。Data Factory によるデータ統合エクスペリエンス、Synapse によるデータ エンジニアリング、データ ウェアハウス、データ サイエンス、リアルタイム分析エクスペリエンス、Power BI を使ったビジネス インテリジェンス (BI) を備えており、これらすべてがレイク中心の SaaS ソリューションでホストされています。 これらのエクスペリエンス用のテナントと容量の管理は、Fabric 管理ポータル (旧称は Power BI 管理ポータル) に一元化されています。
2023 年 6 月より、Power BI 管理者ロールの名称は、この役割のスコープと責任の変化に合わせて、Fabric 管理者に変更されます。 Microsoft Entra ID、Microsoft Graph API、Microsoft 365、GDAP を含むすべてのアプリケーションには、今後数週間で新しいロール名が反映される予定です。
アプリケーション コードやスクリプトでは、ロール名や表示名に基づいて決定を下さないように注意してください。
2021 年 12 月
AD FS ユーザーには、正しいユーザーがサインインしていることを確認するための追加のログイン プロンプトが表示されます。
発効日: 2021 年 12 月
影響を受けるエンドポイント: 統合 Windows 認証
影響を受けるプロトコル: 統合 Windows 認証
変更
現在、ユーザーは認証のために AD FS に送られると、AD FS とのセッションが既に存在するアカウントに自動的にサインインさせられます。 この自動サインインは、ユーザーが別のユーザー アカウントにサインインするつもりであっても発生します。 この誤ったサインインの発生頻度を減らすために、12 月より、Windows の Web アカウント マネージャーがサインイン時にサインインに特定のユーザーが必要であることを示すパラメーター login_hint を Microsoft Entra ID に提供した場合、Microsoft Entra ID は AD FS にパラメーター prompt=login を送信するようになります。
上記の要件が満たされている場合 (サインインに向けてユーザーを Microsoft Entra ID に送信するために WAM が使用され、login_hint が含まれており、ユーザーのドメインの AD FS インスタンスが prompt=login をサポートしている場合)、ユーザーは自動的にサインインされません。代わりに AD FS にサインインし続けるユーザー名を指定する必要があります。 既存の AD FS セッションにサインインする場合は、ログイン プロンプトの下に表示される [現在のユーザーとして続行] オプションを選択できます。 それ以外の場合は、サインインに使用するユーザー名で続行できます。
この変更は、2021 年 12 月、数週間にかけて展開されます。 次の場合、サインインの動作は変更されません。
- IWA を直接使用するアプリケーション
- OAuth を使用するアプリケーション
- AD FS インスタンスにフェデレーションされていないドメイン
2021 年 10 月
対話型認証中にエラー 50105 がinteraction_required返されない問題を修正しました
発効日: 2021 年 10 月
影響を受けるエンドポイント: v2.0 および v1.0
影響を受け取るプロトコル: ユーザー割り当て を必要とするアプリのすべてのユーザー フロー
変更
割り当てられていないユーザーが、管理者がユーザー割り当てを要求するとマークしたアプリにサインインしようとすると、エラー 50105 (現在の指定) が生成されます。 これは一般的なアクセス制御パターンであり、ユーザーは多くの場合、アクセスのブロックを解除するために割り当てを要求する管理者を見つける必要があります。 エラーには、interaction_requiredエラー応答を正しく処理する適切にコード化されたアプリケーションで無限ループを引き起こすバグが存在しました。 interaction_required はアプリに対話型認証を実行するよう指示しますが、それを実行した後にも、Microsoft Entra ID が引き続き interaction_required エラー応答を返すようになっていました。
エラー シナリオが更新されたので、非対話型認証 (prompt=noneはUX を非表示にする場合) に、interaction_requiredエラー応答を使用して対話型認証を実行するようにアプリに指示されます。 その後の対話型認証では、Microsoft Entra ID がユーザーを保持し、エラーメッセージを直接表示して、ループが発生しないようにします。
アプリケーション コードでは、AADSTS50105 のようなエラー コード文字列に基づいて決定を行うべきではないことに注意してください。 代わりに、エラー処理に関するガイダンスに従い、応答の標準 error フィールドにある interaction_required や login_required のような標準化された認証応答を使用します。 他の応答フィールドは、問題のトラブルシューティングを行う人間による使用のみを目的としています。
エラー検索サービス https://login.microsoftonline.com/error?code=50105 では、50105 エラーの現在のテキストと詳細を確認できます。
シングル テナント アプリケーションの AppId URI には、既定のスキームまたは検証済みドメインを使用する必要があります
発効日: 2021 年 10 月
影響を受けるエンドポイント: v2.0 および v1.0
影響を受けるプロトコル:すべてのフロー
変更点
シングル テナント アプリケーションの場合、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 形式がサポートされます。 表の後の一覧の説明に従って、プレースホルダーの値を置き換えてください。
| サポートされるアプリケーション ID URI 形式 |
アプリ ID URI の例 |
|---|---|
| api://<appId> | api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| api://<tenantId>/<appId> | api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| api://<tenantId>/<string> | api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api |
| api://<string>/<appId> | api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed |
| https://<tenantInitialDomain>.onmicrosoft.com/<string> | https://contoso.onmicrosoft.com/productsapi |
| https://<verifiedCustomDomain>/<string> | https://contoso.com/productsapi |
| https://<string>.<verifiedCustomDomain> | https://product.contoso.com |
| https://<string>.<verifiedCustomDomain>/<string> | https://product.contoso.com/productsapi |
- <appId> - アプリケーション オブジェクトのアプリケーション ID (appId) プロパティ。
- <string> - ホストまたは API パスのセグメントの文字列値。
- <tenantId> - Azure 内のテナントを表すために Azure によって生成された GUID。
- <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com。<tenantInitialDomain> は、テナント作成時にテナント作成者が指定した初期ドメイン名です。
- <verifiedCustomDomain> - Microsoft Entra テナント用に構成された検証済みのカスタム ドメイン。
Note
api:// スキームを使用している場合は、"api://" の直後に文字列値を追加します。 たとえば、api://<string> です。 その文字列値には、GUID または任意の文字列を指定できます。 GUID 値を追加する場合は、アプリ ID またはテナント ID と一致する必要があります。 アプリケーション ID URI の値は、テナントに対して一意である必要があります。 アプリケーション ID URI として api://<tenantId> を追加すると、他の誰も他のアプリでその URI を使用できなくなります。 代わりに api://<appId>、または HTTP スキームを使用することをお勧めします。
重要
アプリケーション ID URI の値は、スラッシュ "/" 文字で終わる必要があります。
注意
現在のテナント内でアプリ登録の identifierUris を削除しても問題はありませんが、identifierUris を削除すると、クライアントが他のアプリ登録で失敗する可能性があります。
2021 年 8 月
条件付きアクセスは、明示的に要求されたスコープに対してのみトリガーされる
発効日: 2021 年 8 月。ロールアウトは、4 月から徐々に開始されます。
影響を受けるエンドポイント: v2.0
影響を受けるプロトコル:動的な同意が使用されているすべてのフロー
現在、動的な同意が使用されているアプリケーションでは、名前を指定して scope パラメーターで要求されなかった場合でも、同意があるすべてのアクセス許可が付与されます。 たとえば、user.read のみが要求されているが、files.read に対する同意も含まれているアプリでは、files.read のために割り当てられている条件付きアクセス要件が強制的に渡される場合があります。
不要な条件付きアクセスのプロンプト数を減らすため、Microsoft Entra ID では、スコープがアプリケーションに提供される方法を変更し、明示的に要求されたスコープのみによって条件付きアクセスがトリガーされるようにします。 "すべて" のスコープを トークンに含めるという Microsoft Entra ID の以前の動作に依存するアプリケーションは、要求されたかどうかに関係なく、スコープが欠落しているために中断される可能性があります。
今後、アプリでは、混合したアクセス許可 (要求されたトークンと、同意はあるが、条件付きアクセスのプロンプトが必要ないもの) が含まれたアクセス トークンを受け取ります。 トークンに対するアクセスのスコープは、トークン応答の scope パラメーターに反映されます。
この変更は、この動作に対して、依存関係が確認されたものを除く、すべてのアプリを対象に行われます。 それらが追加の条件付きアクセス プロンプトに依存している可能性があるため、この変更から除外されている場合、開発者はアウトリーチを受け取ります。
使用例
アプリには、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 つすべてのアクセス許可が含まれたトークンを再び発行します。
2021 年 6 月
デバイス コード フロー UX にアプリの確認プロンプトが含まれるようになります
発効日: 2021 年 6 月。
影響を受けるエンドポイント: v2.0 および v1.0
影響を受けるプロトコル: デバイス コード フロー
フィッシング攻撃を防ぐために、デバイス コード フローに、ユーザーが予想するアプリにサインインしていることを検証するプロンプトが含まれるようになりました。
表示されるプロンプトは次のように表示されます。
2020 年 5 月
バグ修正: Microsoft Entra ID が状態パラメーターを 2 回 URL エンコードしなくなります
発効日: 2021 年 5 月
影響を受けるエンドポイント: v1.0 および v2.0
影響を受けるプロトコル: /authorize エンドポイントにアクセスするすべてのフロー (暗黙のフローおよび承認コードフロー)
Microsoft Entra 承認応答でバグが見つかり、修正されました。 認証の /authorize 段階では、応答に要求からの state パラメーターが含まれます。これにより、アプリの状態が維持され、CSRF 攻撃を防ぐことができます。 state パラメーターがエンコードされた応答に、このパラメーターを挿入する前に、Microsoft Entra ID により、誤ってこのパラメーターがもう一度 URL エンコードされます。 これにより、アプリケーションが Microsoft Entra ID からの応答を誤って拒否する可能性があります。
Microsoft Entra ID によるこのパラメーターのダブルエンコードがなくなり、アプリで結果を正しく解析できるようになります。 この変更はすべてのアプリケーションに対して行われます。
Azure Government エンドポイントの変更
発効日: 2020 年 5 月 5 日 (2020 年 6 月終了)
影響を受けるエンドポイント:All
影響を受けるプロトコル:すべてのフロー
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 ブログ記事を参照してください。
2020 年 3 月
ユーザーのパスワードは、256 文字に制限されます。
発効日:2020 年 3 月 13 日
影響を受けるエンドポイント:All
影響を受けるプロトコル:すべてのユーザー フローです。
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.
修復:
パスワードが許可されている最大長を超えているため、ユーザーはログインできません。 パスワードをリセットするには、管理者に連絡する必要があります。 テナントで SSPR が有効になっている場合は、[パスワードを忘れた場合] のリンクを使用してパスワードをリセットできます。
2020 年 2 月
ログイン エンドポイントからのすべての HTTP リダイレクトに空のフラグメントが追加されます。
発効日:2020 年 2 月 8 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル: response_type=query を使用する OAuth および OIDC フロー。これには、承認コード フロー (場合による) と暗黙のフローが含まれます。
login.microsoftonline.com から HTTP リダイレクト経由で認証応答がアプリケーションに送信されると、サービスによって空のフラグメントが応答 URL に追加されます。 これにより、ブラウザーで認証要求内の既存のフラグメントがすべて消去され、リダイレクト攻撃のクラスを防止できます。 アプリはこの動作に依存しないようにしてください。
2019 年 8 月
POST フォームのセマンティクスがより厳密に適用され、スペースおよび引用符は無視されます
発効日:2019 年 9 月 2 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:POST が使用されるすべての場所 (クライアント資格情報、承認コードの利用、ROPC、OBO、および更新トークンの利用)
2019 年 9 月 2 日の週から、POST メソッドを使用する認証要求は、より厳格な HTTP 標準を使用して検証されます。 具体的には、スペースと二重引用符 (") が要求フォームの値から削除されなくなります。 これらの変更によって、既存のクライアントが中断されることはなく、Microsoft Entra ID に送信された要求は毎回確実に処理されます。 今後 (上記参照)、重複するパラメーターを拒否し、要求内の BOM を無視することをさらに計画しています。
例:
現在、?e= "f"&g=h は ?e=f&g=h と同じように解析されるため、e == f となります。 この変更により、これは e == "f" と解析されるようになりました。これは有効な引数である可能性が低く、要求は失敗します。
2019 年 7 月
シングルテナント アプリケーションのアプリ専用トークンは、クライアント アプリがリソース テナントに存在する場合にのみ発行される
発効日:2019 年 7 月 26 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:クライアント資格情報 (アプリ専用トークン)
(クライアント資格情報の付与による) アプリ専用トークンの発行方法を変更するセキュリティの変更が、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.
この問題を解決するには、管理者の同意エクスペリエンスを使ってテナントにクライアント アプリケーション サービス プリンシパルを作成するか、手動で作成します。 この要件により、テナントによってアプリケーションにテナント内で動作するアクセス許可が付与されていることが確認されます。
要求の例
https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... この例では、リソース テナント (機関) は contoso.com、リソース アプリは Contoso テナントに対する gateway.contoso.com/api という名前のシングルテナント アプリ、クライアント アプリは 00001111-aaaa-2222-bbbb-3333cccc4444 です。 クライアント アプリが Contoso.com 内にサービス プリンシパルを持っている場合は、この要求を続行できます。 そうでない場合、要求は上記のエラーで失敗します。
ただし、Contoso ゲートウェイ アプリがマルチテナント アプリケーションの場合は、クライアント アプリのサービス プリンシパルが Contoso.com 内にあるかどうかに関係なく、要求は続行されます。
リダイレクト URI にクエリ文字列パラメーターを含めることができるようになった
発効日:2019 年 7 月 22 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:すべてのフロー
RFC 6749 に従って、Microsoft Entra アプリケーションでは、OAuth 2.0 要求に対する静的クエリ パラメーター (https://contoso.com/oauth2?idp=microsoft など) でリダイレクト (応答) URI を登録して使用できるようになりました。 動的リダイレクト URI は、セキュリティ上のリスクがあり、認証要求全体で状態情報を保持するために使用できないため、引き続き許可されません。そのためには、state パラメーターを使用します。
静的クエリ パラメーターは、リダイレクト URI の他の部分と同様に、リダイレクト URI の文字列照合の対象になります。URI でデコードされたリダイレクト URI に一致する文字列が登録されていない場合、要求は拒否されます。 アプリの登録で URI が見つかった場合は、静的クエリ パラメーターを含む文字列全体が、ユーザーをリダイレクトするために使われます。
現時点 (2019 年 7 月末) では、Azure portal のアプリ登録 UX では、クエリ パラメーターが引き続きブロックされます。 ただし、アプリケーション マニフェストを手動で編集して、クエリ パラメーターを追加し、アプリでこれをテストすることができます。
2019 年 3 月
クライアントのループ処理が中断されます
発効日:2019 年 3 月 25 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:すべてのフロー
クライアント アプリケーションが誤動作し、短期間に数百の同じログイン要求を発行する場合があります。 これらの要求は成功する場合もしない場合もありますが、そのすべてがユーザー エクスペリエンスの低下や IDP のワークロードの増加につながるため、すべてのユーザーの待ち時間が長くなり、IDP の可用性が低下します。 これらのアプリケーションは通常の使用の範囲外で動作しており、正しく動作するように更新する必要があります。
重複した要求を複数回発行するクライアントには invalid_grant エラー: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request が送信されます。
ほとんどのクライアントは、動作を変更してこのエラーを回避する必要はありません。 正しく構成されていない (トークンのキャッシュを使用していない、または既にプロンプト ループを示している) クライアントのみがこのエラーの影響を受けます。 クライアントは、次の要因に対して (Cookie 経由で) ローカルにインスタンスごとに追跡されます。
ユーザー ヒント (存在する場合)
要求されているスコープまたはリソース
クライアント ID
リダイレクト URI
応答の種類とモード
短期間 (5 分) に複数の (15 を超える) 要求を発行しているアプリは、ループ処理していることを示す invalid_grant エラーを受信します。 要求されているトークンには十分に長い有効期間 (最小 10 分、既定では 60 分) があるため、この期間にわたって繰り返される要求は必要ありません。
すべてのアプリが、確認なしでトークンを要求するのではなく、対話型プロンプトを示すことによって invalid_grant を処理する必要があります。 このエラーを回避するために、クライアントは、受信したトークンを正しくキャッシュしていることを確認する必要があります。
2018 年 10 月
認証コードを再利用できなくなりました
発効日:2018 年 11 月 15 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:コード フロー
2018 年 11 月 15 日以降、Microsoft Entra ID では、以前使用されていた、アプリの認証コードの受け入れが停止されます。 このセキュリティの変更により、Microsoft Entra ID と OAuth の仕様が一致するようになります。この変更は、v1 と v2 両方のエンドポイントに適用されます。
お使いのアプリで承認コードを再利用して複数のリソースに対するトークンを取得している場合は、コードを使用して更新トークンを取得した後、その更新トークンを使用して他のリソース用のトークンを追加取得することお勧めします。 承認コードは 1 回しか使用できませんが、更新トークンは複数のリソースで複数回使用できます。 OAuth コード フローの使用時に新しいアプリで認証コードを再利用しようとすると、invalid_grant エラーが発生します。
更新トークンについて詳しくは、「アクセス トークンの更新」をご覧ください。 ADAL または MSAL を使用する場合、これはライブラリによって処理されます。AcquireTokenByAuthorizationCodeAsync の 2 番目のインスタンスを AcquireTokenSilentAsync に置き換えます。
2018 年 5 月
ID トークンは、OBO フローに使用できません
日付:2018 年 5 月 1 日
影響を受けるエンドポイント:v1.0 と v2.0 の両方
影響を受けるプロトコル:暗黙的フローと On-Behalf-Of フロー
2018 年 5 月 1 日以降、id_tokens は新しいアプリケーションの OBO フローでアサーションとして使用できません。 代わりに、アクセス トークンを使用して、同じアプリケーションのクライアントと中間層の間でも、API のセキュリティを確保する必要があります。 2018 年 5 月 1 日より前に登録されたアプリは、引き続き動作し、id_tokens をアクセス トークンに交換することができますが、このパターンはベスト プラクティスとは見なされません。
この変更を回避するには、次の操作を行います。
- 1 つ以上のスコープを使用して、アプリケーション用の Web API を作成します。 この明示的なエントリ ポイントにより、きめ細かな制御とセキュリティが可能になります。
- アプリのマニフェスト、Azure portal、またはアプリ登録ポータルで、アプリが暗黙のフローを介してアクセス トークンを発行できることを確認します。 これは
oauth2AllowImplicitFlowキーによって制御されます。 - クライアント アプリケーションで
response_type=id_tokenを使用して id_token を要求した場合、上記で作成した Web API に対してもアクセス トークン (response_type=token) を要求します。 したがって、v2.0 エンドポイントを使用する場合、scopeパラメータはapi://GUID/SCOPEと同様のものになります。 v1.0 エンドポイントでは、resourceパラメータを Web API のアプリ URI にする必要があります。 - このアクセストークンを、id_token の代わりに、中間層に渡します。