トークンと要求の概要

  • [アーティクル]

一元化された ID プロバイダーは、世界中にいるユーザーが必ずしも企業のネットワークからサインインするわけではないアプリにとって特に役立ちます。 Microsoft ID プラットフォームではユーザーを認証し、セキュリティ トークン (アクセス トークン、リフレッシュトークン、ID トークンなど) を提供します。 セキュリティ トークンを使用すると、クライアント アプリケーションは、リソース サーバー上の保護されたリソースにアクセスできます。

  • アクセス トークン - アクセス トークンは、OAuth 2.0 フローの一部として承認サーバーによって発行されるセキュリティ トークンです。 これには、そのトークンの対象となるユーザーとリソースに関する情報が含まれています。 この情報を使用すると、Web API やその他の保護されたリソースにアクセスできます。 リソースはアクセス トークンを検証して、クライアント アプリケーションへのアクセスを許可します。 詳細については、「Microsoft ID プラットフォームのアクセス トークン」を参照してください。
  • 更新トークン - アクセス トークンは短時間しか有効でないため、承認サーバーでは、アクセス トークンの発行と同時に更新トークンを発行する場合があります。 クライアント アプリケーションでは、必要に応じて、このリフレッシュトークンを新しいアクセス トークンに交換できます。 詳細については、「Microsoft ID プラットフォームの更新トークン」を参照してください。
  • ID トークン - ID トークンは、OpenID Connect フローの一部としてクライアント アプリケーションに送信されます。 これらは、アクセス トークンの代わりに、またはアクセス トークンと共に送信できます。 ID トークンは、ユーザーを認証するためにクライアントによって使用されます。 Microsoft ID プラットフォームが ID トークンを発行する方法の詳細については、「Microsoft ID プラットフォームの ID トークン」を参照してください。

多くのエンタープライズ アプリケーションは、SAML を使用してユーザーを認証します。 SAML アサーションの詳細については、「SAML トークンのリファレンス」を参照してください。

トークンを検証する

トークンの検証は、そのトークンが生成されたアプリケーション、ユーザーをサインインさせた Web アプリ、または呼び出し先の Web API に任されています。 承認サーバーは、秘密キーを使用してトークンに署名します。 承認サーバーでは、対応する公開キーを発行します。 トークンを検証するために、アプリでは、承認サーバーの公開キーを使用して署名を検証することによって、その署名が秘密キーを使用して作成されたことを検証します。 詳しくは、「要求を検証してアプリケーションと API をセキュリティで保護する」に関する記事をご覧ください。

可能な限り、サポートされている Microsoft 認証ライブラリ (MSAL) を使用することをおすすめします。 これにより、トークンの取得、更新、検証が実装されます。 また、テナントの OpenID の既知の検出ドキュメントを使用して、標準に準拠したテナント設定とキーの検出を実装します。 MSAL は、.NET、JavaScript、Java、Python、Android、iOS などの、さまざまなアプリケーション アーキテクチャとプラットフォームをサポートします。

トークンは限られた時間だけ有効であるため、承認サーバーはトークンのペアを頻繁に提供します。 アクセス トークンが提供されます。これは、アプリケーションまたは保護されたリソースにアクセスします。 更新トークンが提供されます。これは、アクセス トークンが有効期限に近づいたとき、そのアクセス トークンを更新するために使用されます。

アクセス トークンは、Authorization ヘッダーのベアラー トークンとして Web API に渡されます。 アプリでは、承認サーバーにリフレッシュトークンを提供できます。 ユーザーのアプリへのアクセスが取り消されなかった場合、アプリは新しいアクセス トークンと新しい更新トークンを受け取ります。 承認サーバーは、更新トークンを受信すると、ユーザーがまだ承認されている場合にのみ次のアクセス トークンを発行します。

JSON Web トークンと要求

Microsoft ID プラットフォームでは、要求を含む JSON Web トークン (JWT) としてセキュリティ トークンを実装します。 JWT はセキュリティ トークンとして使用されるため、この認証形式は JWT 認証と呼ばれることがあります。

要求では、一方のエンティティ (クライアント アプリケーション、リソース所有者など) に関するアサーションが、もう一方のエンティティ (リソース サーバーなど) に渡されます。 要求は、JWT 要求または JSON Web トークン要求と呼ばれることもあります。

要求は、トークン サブジェクトに関するファクトを中継する名前または値のペアです。 たとえば、ある要求に、承認サーバーが認証したセキュリティ プリンシパルに関するファクトが含まれていることがあります。 特定のトークン内に存在する要求は、トークンの種類、サブジェクトを認証するために使用される資格情報の種類、アプリケーション構成など、多くのものによって異なります。

アプリケーションでは、以下のような各種タスクのために要求を使用できます:

  • トークンを検証する
  • トークン サブジェクトのテナントを識別する
  • ユーザー情報を表示する
  • サブジェクトの承認を判断する

要求は、以下のような種類の情報を提供するキーと値のペアで構成されます:

  • トークンを生成したセキュリティ トークン サーバー
  • トークンが生成された日付
  • サブジェクト (ユーザーと同じですが、デーモンは含まれません)
  • 対象ユーザー。トークンが生成されたアプリです
  • トークンを要求したアプリ (クライアント)

トークン エンドポイントと発行者

Microsoft Entra ID では、2 つのテナント構成がサポートされています。社内での使用を目的として、従業員とビジネス ゲストを管理する従業員構成と、 制限された外部向けディレクトリ内のコンシューマーとパートナーを分離するために最適化された顧客構成 です。 基になる ID サービスはどちらのテナント構成でも同じですが、外部テナントに対するログイン ドメインとトークン発行機関は異なります。 これにより、必要に応じて、アプリケーションで従業員と外部 ID のワークフローを分離し続けることができます。

Microsoft Entra の従業員テナントでは、sts.windows.net によって発行されたトークンを使用して、login.microsoftonline.comで認証を行います。 一般に、ワークフォース テナント トークンは、基になる信頼関係によってこの相互運用性が許可されている限り、テナントとマルチテナント アプリケーション間で交換可能です。 Microsoft Entra の外部テナントでは、{tenantname}.ciamlogin.com という形式のテナント化されたエンドポイントが使われます。 外部テナントに登録されているアプリケーションでは、トークンを正しく受信して検証するために、この分離を認識している必要があります。

すべての Microsoft Entra テナントは、標準準拠の既知のメタデータを発行します。 このドキュメントには、発行者名、認証および承認エンドポイント、サポートされているスコープと要求に関する情報が含まれています。 外部テナントの場合、ドキュメントは https://{tenantname}.ciamlogin.com/{tenantid}/v2.0/.well-known/openid-configuration で公開されています。 このエンドポイントは、発行者値 https://{tenantid}.ciamlogin.com/{tenantid}/v2.0 を返します。

承認フローと認証コード

クライアントの構築方法に応じて、Microsoft ID プラットフォームでサポートされている認証フローの 1 つ (または複数) を使用できます。 サポートされているフローでは、各種のトークンと承認コードを生成でき、それらを機能させるためにさまざまなトークンが必要です。 以下の表に概要を示します。

Flow 必要 ID トークン アクセス トークン リフレッシュトークン Authorization code (承認コード)
承認コード フロー x x x x
暗黙的なフロー x x
ハイブリッド OIDC フロー x x
更新トークンの使用 リフレッシュトークン x x x
On-Behalf-Of フロー アクセス トークン x x x
クライアントの資格情報 x (アプリのみ)

暗黙的フローで発行されたトークンは、URL 経由でブラウザーに戻される (ここで、response_mode は query または fragment) ため、長さに制限があります。 一部のブラウザーは、ブラウザー バーに表示できる URL のサイズに制限があるため、それが長すぎると失敗します。 その結果、これらのトークンに groups または wids 要求はありません。

関連項目

次のステップ

  • 認証と承認の基本的な概念については、「認証と承認」を参照してください。