重要
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
Azure Active Directory B2C (Azure AD B2C) は、OpenID Connect と OAuth 2.0 の 2 つの業界標準プロトコルをサポートすることで、アプリのサービスとしての ID を提供します。 サービスは標準に準拠していますが、これらのプロトコルの 2 つの実装には微妙な違いがあります。
このガイドの情報は、オープン ソース ライブラリを使用するのではなく、HTTP 要求を直接送信および処理してコードを記述する場合に役立ちます。 各特定のプロトコルの詳細を確認する前に、このページをお読みすることをお勧めします。 ただし、Azure AD B2C に既に慣れている場合は、 プロトコル リファレンス ガイドに直接進むことができます。
基本的なこと
Azure AD B2C を使用するすべてのアプリは、 Azure portal の B2C ディレクトリに登録する必要があります。 アプリ登録プロセスでは、いくつかの値が収集され、アプリに割り当てられます。
アプリを一意に識別する アプリケーション ID 。
応答をアプリに送り返すために使用できる リダイレクト URI または パッケージ識別子 。
その他のシナリオ固有の値。 詳細については、 アプリケーションを登録する方法を参照してください。
アプリを登録すると、エンドポイントに要求を送信することで Azure AD B2C と通信します。
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
カスタム ドメインを使用している場合は、{tenant}.b2clogin.comをエンドポイントのカスタム ドメイン (contoso.com など) に置き換えます。
ほぼすべての OAuth フローと OpenID Connect フローで、4 つの関係者が交換に関与します。
承認サーバーは、Azure AD B2C エンドポイントです。 ユーザー情報とアクセスに関連するあらゆるものを安全に処理します。 また、フロー内の当事者間の信頼関係も処理します。 ユーザーの ID の検証、リソースへのアクセスの許可と取り消し、トークンの発行を担当します。 これは ID プロバイダーとも呼ばれます。
通常、 リソース所有者 はエンド ユーザーです。 データを所有するのは当事者であり、第三者がそのデータまたはリソースにアクセスできるようにする権限を持っています。
OAuth クライアントはあなたのアプリです。 アプリケーション ID によって識別されます。 通常は、エンド ユーザーがやり取りするパーティーです。 また、承認サーバーからトークンを要求します。 リソース所有者は、リソースにアクセスするためのアクセス許可をクライアントに付与する必要があります。
リソース サーバーは、リソースまたはデータが存在する場所です。 承認サーバーを信頼して、OAuth クライアントを安全に認証および承認します。 また、ベアラー アクセス トークンを使用して、リソースへのアクセスを確実に付与できます。
ポリシーとユーザー フロー
Azure AD B2C では、ポリシーを導入することで、標準の OAuth 2.0 プロトコルと OpenID Connect プロトコルが拡張されます。 これにより、Azure AD B2C は単純な認証と承認よりもはるかに多くを実行できます。
最も一般的な ID タスクを設定するために、Azure AD B2C ポータルには、 ユーザー フローと呼ばれる定義済みの構成可能なポリシーが含まれています。 ユーザー フローは、サインアップ、サインイン、プロファイル編集など、コンシューマー ID エクスペリエンスを完全に記述します。 ユーザー フローは、管理 UI で定義できます。 これらは、HTTP 認証要求で特殊なクエリ パラメーターを使用して実行できます。
ポリシーとユーザー フローは、OAuth 2.0 と OpenID Connect の標準的な機能ではありません。そのため、時間をかけて理解する必要があります。 詳細については、 Azure AD B2C ユーザー フロー リファレンス ガイドを参照してください。
トークン
OAuth 2.0 と OpenID Connect の Azure AD B2C 実装では、JSON Web トークン (JWT) として表されるベアラー トークンなど、ベアラー トークンを幅広く使用しています。 ベアラー トークンは、保護されたリソースへの "ベアラー" アクセスを許可する軽量のセキュリティ トークンです。
ベアラーは、トークンを提示できる任意のパーティです。 Azure AD B2C は、ベアラー トークンを受け取る前に、まずパーティを認証する必要があります。 ただし、転送およびストレージ内のトークンをセキュリティで保護するために必要な手順が実行されない場合は、意図しないパーティによって傍受され、使用される可能性があります。
一部のセキュリティ トークンには、承認されていないパーティが使用できないようにする組み込みのメカニズムがありますが、ベアラー トークンにはこのメカニズムがありません。 トランスポート層セキュリティ (HTTPS) などのセキュリティで保護されたチャネルで転送する必要があります。
ベアラー トークンがセキュリティで保護されたチャネルの外部で送信された場合、悪意のあるパーティは中間者攻撃を使用してトークンを取得し、それを使用して保護されたリソースへの不正アクセスを取得できます。 ベアラー トークンを後で使用するために格納またはキャッシュする場合も、同じセキュリティ原則が適用されます。 アプリがベアラー トークンを安全な方法で送信して格納することを常に確認してください。
ベアラー トークンのセキュリティに関する追加の考慮事項については、 RFC 6750 セクション 5 を参照してください。
Azure AD B2C で使用されるさまざまな種類のトークンの詳細については、 Azure AD B2C トークン リファレンスを参照してください。
プロトコル
要求の例を確認する準備ができたら、次のいずれかのチュートリアルから始めることができます。 それぞれは、特定の認証シナリオに対応します。 適切なフローの判断に関するヘルプが必要な場合は、 Azure AD B2C を使用してビルドできるアプリの種類を確認してください。