次の方法で共有

Microsoft ID プラットフォームにおける OAuth 2.0 と OpenID Connect (OIDC)

  • [アーティクル]

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

OAuth 2.0 でのロール

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

OAuth 2.0 ロールを示す図

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

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

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

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

トークン

認証フロー内のパーティは、ベアラー トークンを使用して、プリンシパル(ユーザー、ホスト、またはサービス)を確認、識別、認証し、保護されたリソースへのアクセスを許可または拒否します (認可)。 ID プラットフォームにおけるベアラー トークンは、JSON Web Token (JWT) 形式です。

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

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

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

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

アプリの登録

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

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

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

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

エンドポイント

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.

登録したアプリケーションのエンドポイントを見つけるには、Azure portal で、次の場所に移動します。

[Azure Active Directory]>[アプリの登録]><お使いのアプリケーション>>[エンドポイント]

次の手順

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

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