次の方法で共有

Microsoft ID プラットフォームでの OAuth 2.0 と OIDC 認証フロー

Microsoft ID プラットフォームを使用するために、プロトコル レベルで OAuth または OpenID Connect (OIDC) を学習する必要はありません。 ただし、ID プラットフォームを使ってアプリに認証を追加するときに、プロトコルの用語と概念が出現します。 Microsoft Entra 管理センター、Microsoft のドキュメント、認証ライブラリを使用して作業する際に、いくつかの基礎を理解することが、統合と全体的なエクスペリエンスの助けとなります。

OAuth 2.0 でのロール

OAuth 2.0 と OpenID Connect での認証と承認の交換には、通常、4 つのパーティーが関与します。 このような交換は、多くの場合、"認証フロー" と呼ばれます。

OAuth 2.0 の役割 (承認サーバー、クライアント、リソース所有者、リソース サーバーなど) を示す図のスクリーンショット

  • 承認サーバー - Microsoft ID プラットフォームが承認サーバーです。 ID プロバイダーまたは IdP とも呼ばれ、エンド ユーザーの情報、アクセス、および認証フロー内の関係者間の信頼関係を安全に処理します。 承認サーバーは、ユーザーがサインインした (認証された) 後に、リソースへのアクセスの許可、拒否、または取り消し (承認) のためにアプリと API が使用するセキュリティ トークンを発行します。

  • クライアント - OAuth 交換のクライアントは、保護されたリソースへのアクセスを要求するアプリケーションです。 クライアントには、サーバーで実行されている Web アプリ、ユーザーの Web ブラウザーで実行されているシングルページ Web アプリ、または別の Web API を呼び出す Web API を使用できます。 多くの場合、クライアントは "クライアント アプリケーション"、"アプリケーション"、または "アプリ" と呼ばれます。

  • リソース所有者 - 認証フローのリソース所有者は、通常、アプリケーション ユーザー、または OAuth 用語の エンド ユーザー です。 エンド ユーザーは、アプリがユーザーの代わりにアクセスする保護されたリソース (ユーザーのデータ) を "所有" します。 リソース所有者は、所有するリソースへのアプリ (クライアント) によるアクセスを許可または拒否できます。 たとえば、アプリは、外部システムの API を呼び出して、そのシステム上のプロファイルからユーザーの電子メール アドレスを取得できます。 プロファイル データは、エンド ユーザーが外部システム上に所有しているリソースであり、エンド ユーザーは、アプリによるデータへのアクセス要求に同意または拒否できます。

  • リソース サーバー - リソース サーバーは、リソース所有者のデータをホストまたはアクセスします。 ほとんどの場合、リソース サーバーは、データ ストアに対処する Web API です。 リソース サーバーは、承認サーバーを利用して、認証を実行します。また、承認サーバーによって発行されたベアラー トークン内の情報を使用して、リソースへのアクセスを許可または拒否します。

トークン

認証フローの関係者は 、ベアラー トークン を使用してプリンシパル (ユーザー、ホスト、またはサービス) を保証、検証、認証し、保護されたリソース (承認) へのアクセスを許可または拒否します。 Microsoft ID プラットフォームのベアラー トークンは、 JSON Web トークン (JWT) として書式設定されます。

ID プラットフォームでは、次の 3 種類のベアラー トークンが "セキュリティ トークン" として使用されます。

  • アクセス トークン - アクセス トークンは、承認サーバーによってクライアント アプリケーションに発行されます。 クライアントは、アクセス トークンをリソース サーバーに渡します。 アクセス トークンには、承認サーバーによってクライアントに付与されたアクセス許可が含まれます。

  • ID トークン - ID トークンは、承認サーバーによってクライアント アプリケーションに発行されます。 クライアントは、ユーザーをサインインするときに、ID トークンを使用して、ユーザーに関する基本情報を取得します。

  • 更新トークン - クライアントは、更新トークン ( RT) を使用して、承認サーバーに新しいアクセストークンと ID トークンを要求します。 更新トークンとその文字列コンテンツは、承認サーバーによる使用のみを目的としているため、コードでは機密データとして扱う必要があります。

アプリの登録

Microsoft ID プラットフォームによってクライアント アプリに発行されたセキュリティ トークンを信頼する方法が必要です。 信頼を確立するための最初の手順は、 アプリを登録することです。 アプリを登録すると、ID プラットフォームは、それにいくつかの値を自動的に割り当てます。他の値は、アプリケーションの種類に基づいて手動で構成します。

最も一般的に参照されるアプリ登録設定は次の 2 つです。

  • アプリケーション (クライアント) ID - アプリケーション ID と クライアント ID とも呼ばれ、この値は ID プラットフォームによってアプリに割り当てられます。 クライアント ID は、ID プラットフォーム内のアプリを一意に識別し、プラットフォームが発行するセキュリティ トークンに含まれます。
  • リダイレクト URI - 承認サーバーは、リダイレクト URI を使用して、リソース所有者の ユーザー エージェント (Web ブラウザー、モバイル アプリ) を、対話の完了後に別の宛先にリダイレクトします。 たとえば、エンド ユーザーが承認サーバーで認証された後にです。 すべてのクライアントの種類でリダイレクト URI が使用されるとは限りません。

アプリの登録時には、ID とアクセス トークンを取得するためにコードで使用する認証と承認の "エンドポイント" に関する情報も保持されます。

エンドポイント

Microsoft ID プラットフォームは、OAuth 2.0 と OpenID Connect (OIDC) 1.0 の標準に準拠した実装を使用して、認証と承認のサービスを提供します。 ID プラットフォームなどの標準準拠の承認サーバーは、フローを実行するために認証フロー内でパーティによって使用される HTTP エンドポイントのセットを提供します。

アプリのエンドポイント URI は、アプリを登録または構成するときに自動的に生成されます。 アプリのコードで使用するエンドポイントは、アプリケーションの種類と、それがサポートする必要がある ID (アカウントの種類) によって異なります。

一般的に使用される 2 つのエンドポイントは、 承認エンドポイント と トークン エンドポイントです。 authorize と token のエンドポイントの例をこちらに示します。

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or ___domain name.

登録したアプリケーションのエンドポイントを検索するには、 Microsoft Entra 管理センター で次の場所に移動します。

Entra ID>アプリの登録><YOUR-APPLICATION>>エンドポイント

次のステップ

次に、それぞれのアプリケーションの種類によって使用される OAuth 2.0 認証フローと、それらを実行するためにアプリ内で使用できるライブラリについて説明します。

認証フローを実行する場合に、独自のライブラリや未加工の HTTP 呼び出しを作成しないことを強くお勧めします。 Microsoft 認証ライブラリは、より安全で簡単です。 ただし、お客様のシナリオで Microsoft のライブラリを使用できない場合、または Microsoft ID プラットフォームの実装の詳細をお知りになりたい場合は、プロトコル リファレンスが用意されています。