Azure AD B2C:認証プロトコルAzure AD B2C: Authentication protocols

Azure Active Directory B2C (Azure AD B2C) では、業界標準である次の 2 つのプロトコルをサポートすることによって Identity-as-a-Service (サービスとしての ID) 機能がアプリに提供されます:OpenID Connect と OAuth 2.0。Azure Active Directory B2C (Azure AD B2C) provides identity as a service for your apps by supporting two industry standard protocols: OpenID Connect and OAuth 2.0. このサービスは標準に準拠していますが、これらのプロトコルには、実装によって微妙な違いが存在する場合があります。The service is standards-compliant, but any two implementations of these protocols can have subtle differences.

ここでは、オープン ソース ライブラリを使うのではなく、コードから直接 HTTP 要求を送信して処理する場合に役立つ情報を紹介します。The information in this guide is useful if you write your code by directly sending and handling HTTP requests, rather than by using an open source library. 特定のプロトコルの詳細を学習する前に、このページを読むことをお勧めします。We recommend that you read this page before you dive into the details of each specific protocol. ただし、Azure AD B2C について既に詳しい場合は、プロトコル リファレンス ガイドにすぐに進んでもかまいません。But if you're already familiar with Azure AD B2C, you can go straight to the protocol reference guides.

基本The basics

Azure AD B2C を使用するすべてのアプリは、 Azure Portal で B2C ディレクトリに登録する必要があります。Every app that uses Azure AD B2C needs to be registered in your B2C directory in the Azure portal. アプリの登録プロセスでは、いくつかの値が収集され、対象のアプリに割り当てられます。The app registration process collects and assigns a few values to your app:

  • アプリを一意に識別する アプリケーション IDAn Application ID that uniquely identifies your app.
  • リダイレクト URI またはパッケージ識別子 (アプリに戻す応答をリダイレクトする際に使用)。A Redirect URI or package identifier that can be used to direct responses back to your app.
  • その他シナリオに応じた値。A few other scenario-specific values. 詳細については、アプリケーションを登録する方法に関する記事を参照してください。For more information, learn how to register your application.

アプリを登録した後は、エンドポイントに要求を送ることによって、Azure Active Directory (Azure AD) と通信を行います。After you register your app, it communicates with Azure Active Directory (Azure AD) by sending requests to the endpoint:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

OAuth と OpenID Connect におけるフローはほぼすべて、情報のやり取りに 4 つの当事者が関係します。In nearly all OAuth and OpenID Connect flows, four parties are involved in the exchange:

4 つの OAuth 2.0 ロールを示す図

  • 承認サーバーは Azure AD エンドポイントです。The authorization server is the Azure AD endpoint. 承認サーバーは、ユーザー情報とアクセスに関するすべてのことを安全に処理します。It securely handles anything related to user information and access. また、フロー内の当事者間の信頼関係も処理します。It also handles the trust relationships between the parties in a flow. ユーザーの本人性確認、リソースへのアクセス権の付与と取り消し、トークンの発行という役割を担います。It is responsible for verifying the user's identity, granting and revoking access to resources, and issuing tokens. ID プロバイダーとも呼ばれます。It is also known as the identity provider.

  • リソース所有者 とは通常、エンド ユーザーを指します。The resource owner is typically the end user. データを所有し、そのデータ (またはリソース) へのアクセスをサード パーティに許可する権限を持つ当事者です。It is the party that owns the data, and it has the power to allow third parties to access that data or resource.

  • OAuth クライアント はアプリです。The OAuth client is your app. アプリケーション ID によって識別されます。It's identified by its Application ID. 通常は、エンド ユーザーと情報をやり取りする当事者です。It's usually the party that end users interact with. また、承認サーバーにトークンを要求します。It also requests tokens from the authorization server. リソース所有者は、リソースにアクセスするためのアクセス許可をクライアントに付与する必要があります。The resource owner must grant the client permission to access the resource.

  • リソース サーバー は、リソースまたはデータが存在する場所です。The resource server is where the resource or data resides. 承認サーバーを信頼し、OAuth クライアントを安全に認証、承認します。It trusts the authorization server to securely authenticate and authorize the OAuth client. また、ベアラー アクセス トークンを使用して、リソースへのアクセス許可を確実に付与します。It also uses bearer access tokens to ensure that access to a resource can be granted.

ポリシーとユーザー フローPolicies and user flows

おそらく、Azure AD B2C のポリシーは、サービスの最も重要な機能です。Arguably, Azure AD B2C policies are the most important features of the service. Azure AD B2C は、ポリシーを導入することによって、標準の OAuth 2.0 や OpenID Connect プロトコルを拡張します。Azure AD B2C extends the standard OAuth 2.0 and OpenID Connect protocols by introducing policies. ポリシーにより、Azure AD B2C は単なる認証および承認以外の多くの機能を実行できます。These allow Azure AD B2C to perform much more than simple authentication and authorization.

最も一般的な ID タスクを設定しやすくするために、Azure AD B2C ポータルには、ユーザー フローという事前定義済みで構成できるポリシーが用意されています。To help you set up the most common identity tasks, the Azure AD B2C portal includes predefined, configurable policies called user flows. ユーザー フローには、サインアップ、サインイン、プロファイル編集など、コンシューマーの ID エクスペリエンスが完全に記述されています。User flows fully describe consumer identity experiences, including sign-up, sign-in, and profile editing. ユーザー フローは、管理 UI で定義できます。User flows can be defined in an administrative UI. ポリシーは、HTTP 認証要求の特別なクエリ パラメーターを使用して実行できます。They can be executed by using a special query parameter in HTTP authentication requests.

ポリシーとユーザー フローは、OAuth 2.0 および OpenID Connect の標準機能ではないので、理解するために時間をかける必要があります。Policies and user flows are not standard features of OAuth 2.0 and OpenID Connect, so you should take the time to understand them. 詳しくは、Azure AD B2C のユーザー フロー リファレンス ガイドに関する記事をご覧ください。For more information, see the Azure AD B2C user flow reference guide.

トークンTokens

Azure AD B2C での OAuth 2.0 および OpenID Connect の実装では、ベアラー トークンが広範囲に使われています (JSON Web トークン (JWT) として表現されたベアラー トークンなど)。The Azure AD B2C implementation of OAuth 2.0 and OpenID Connect makes extensive use of bearer tokens, including bearer tokens that are represented as JSON web tokens (JWTs). ベアラー トークンは、保護されたリソースへの "ベアラー" アクセスを許可する簡易セキュリティ トークンです。A bearer token is a lightweight security token that grants the "bearer" access to a protected resource.

ベアラーは、トークンを提示できる任意の利用者を表します。The bearer is any party that can present the token. Azure AD は、ベアラー トークンを受信するには、最初に利用者を認証する必要があります。Azure AD must first authenticate a party before it can receive a bearer token. ただし、転送中や保存時にトークンを保護するために必要な対策を講じていない場合、意図しない利用者によって傍受され、使用されるおそれがあります。But if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party.

一部のセキュリティ トークンには、許可されていない利用者がトークンを使用できないようにするための組み込みメカニズムがありますが、ベアラー トークンにはこのメカニズムがありません。Some security tokens have built-in mechanisms that prevent unauthorized parties from using them, but bearer tokens do not have this mechanism. トランスポート層セキュリティ (HTTPS) などのセキュリティ保護されたチャネルで転送する必要があります。They must be transported in a secure channel, such as a transport layer security (HTTPS).

ベアラー トークンがセキュリティ保護されたチャネル以外で転送された場合、悪意のある利用者が中間者攻撃によってトークンを取得し、保護されたリソースへの未承認のアクセスに使用する可能性があります。If a bearer token is transmitted outside a secure channel, a malicious party can use a man-in-the-middle attack to acquire the token and use it to gain unauthorized access to a protected resource. 後で使用するためにベアラー トークンを保存またはキャッシュするときにも、同じセキュリティ原則が適用されます。The same security principles apply when bearer tokens are stored or cached for later use. アプリケーションでは、常に安全な方法でベアラー トークンを転送および保存してください。Always ensure that your app transmits and stores bearer tokens in a secure manner.

ベアラー トークンのセキュリティに関する考慮事項の詳細については、 RFC 6750 セクション 5を参照してください。For additional bearer token security considerations, see RFC 6750 Section 5.

Azure AD B2C で使われている各種トークンの詳細については、Azure AD のトークン リファレンスを参照してください。More information about the different types of tokens that are used in Azure AD B2C are available in the Azure AD token reference.

プロトコルProtocols

要求の例を確認できる状態になったら、次のいずれかのチュートリアルを開始できます。When you're ready to review some example requests, you can start with one of the following tutorials. いずれも、特定の認証シナリオに対応しています。Each corresponds to a particular authentication scenario. どのフローを見ればよいかわからない場合は、Azure AD B2C で作成できるアプリの種類を確認してください。If you need help determining which flow is right for you, check out the types of apps you can build by using Azure AD B2C.