【丁寧解説】Azure AD B2C とは？

更新日 2021/01/29

作成日 2020/11/02

はじめに

Azure AD B2C(以下 AAD B2C) はAzure AD の1サービスです。

Azure AD B2C を使うと迅速に認証や認可部分の機能を立ち上げることができます。

ユーザー登録や情報更新、ログイン、パスワード変更といったアカウント機能は、自前で毎回作りこむとそれなりに大変ですが、 自分たちで作らずに他のサービスを利用した方が、自分たちのサービスを手早く立ち上げられ、且つ安全という世の中になってきています。

そこでこれから数回に渡り Azure AD B2C についてまとめていきます。

AAD B2C とは

AAD B2C の概要は、下記のような構造です。

AAD B2C は、B2C 向けの Id 基盤を提供するサービスです。

所謂 IDaaS (Identity as as Service) と呼ばれるサービスです。

アプリケーションのユーザは、任意の SNS アカウントやメールアドレス、既存の AAD などを使用してアプリケーションへサインアップ・サインインすることが出来ます。

AAD B2C は、Web アプリ、ネイティブアプリ問わず、幅広いアプリケーションで利用可能です。

開発用の SDK も提供されていますが、標準化された認証プロトコルを使用しているため、SDK 無しでも様々なアプリケーションや製品と統合することが出来ます。

ユーザ情報を AAD B2C に統合することも可能ですが、ユーザの詳細な情報を Dynamics や Salesforce といった CRM 、外部の DB などと統合することも可能です。

価格に関しても、競合の Auth0 や Cognito などと比較しても比較的低価格で提供されているため、導入コストも比較的低く済みます。(価格については、後述)

AAD B2C の構成

AAD B2C の構成は、非常にシンプルなものであり、基本的に通常の AAD とそれをコンシューマ向けに使用するためのアプリケーションで構成されています。

AAD B2C を作成すると、新たな AAD のテナントが作成されます。 作成されたテナント内の AAD へ、b2c-extensions-app というアプリケーションが自動で登録されます。

AAD B2C のユーザ情報を扱うといった機能は、b2c-extensions-app が提供する機能のため、このアプリケーションは、絶対に変更してはいけません。 自動で作成されるものなので、よくわからないから削除するといったことをしないように気を付けましょう。

このアプリケーションが削除された場合、AAD B2C が正しく機能しなくなります。

仮にこのアプリケーションを削除した場合は、30日間待った後に完全に削除されます。 そのため誤って削除した場合は、30日以内であれば、復元可能です。

誤って削除しないように細心の注意を払いましょう。

IDaaS導入のメリット

IDaaS を導入しなかった場合に考えられるあれこれ

IDaaS 導入は、様々なメリットがあります。

まず、認証基盤を自前で作った場合に考えられる懸念点などを考えてみましょう。

• センシティブな情報を直接扱う必要がある(顧客情報が大量に含まれた DB を直接管理する必要がある)
• 強い認証方式を用意する必要がある
• 実装ミスによって顧客のパスワードが流出下といったことが発生しうる
  • パスワードが平文で保存されていた
  • パスワードを暗号化していたが、暗号化前のパスワードがログに出力されていた
  • etc
• 認証基盤を載せたインフラの継続的なメンテナンス・更新

自前で認証基盤を作ると少し考えただけでも上記の様に色々と考えないといけないことが出てきます。 IDaaS を使用した場合、これらは、基本的にサービス提供者が担保してくれていると考えて良いため、実装・運用のコストを大幅に下げることが出来ます。

IDaaS を使わない場合のデメリットや大変な事のあれこれを簡単に書き出してみました。 では、メリットは、どんなことが思い浮かぶでしょうか。

複数アプリで使用できる共通基盤をすぐに用意出来る

作っているサービスが様々な関連サービスに展開していくことを考えてみましょう。 例えば3つのサービスを作り、認証基盤を統一したい場合どのように実装したらよいでしょうか。

1. それぞれ認証の仕組みを作り、DB だけ共通のものを使う
2. 共通 Id を発行する認証基盤を作りこみ、それぞれのサービスで繋ぎこみを行う
3. IDaaS で認証基盤を用意し、それぞれのサービスで繋ぎこみを行う

1 は、そもそもそれぞれ認証の仕組みから作りこむ必要があるので非常にコスト高です。 また DB だけ共通で実質バラバラなサービスのような形になります。

2 は、IDaaS で補える部分を自前で実装することになります。 ということは、わざわざ認証基盤として使うアプリケーションをもう一つ用意する必要があります。 当初 3つのサービスを作りたかったはずなのに作るべきサービスが 4つになってしまいました。

3 は、それぞれのサービスを認証基盤に繋ぎこむという意味では、同じですが、認証基盤自体を作りこむ必要がなくなったので、全体で一番コストを下げることが出来ました。

このように、IDaaS を認証基盤として使用すると、わざわざ作りこむ箇所が減るため非常にコストを下げることが出来ます。

ハイパフォーマンス、高可用性を実現出来る

認証基盤は、サービスの要です。

この部分が貧弱だと、サインイン・サインアップが滞るなど、ユーザ体験を著しく損なう可能性があります。 自前で認証基盤を用意する場合、急なユーザの増加などを考慮したインフラ設計なども必要になり、様々な考慮事項が発生します。

IDaaS では、高パフォーマンス、高可用性を IDaaS 側が担保してくれるため、サービスの根幹に関わるような問題を未然に防ぎやすいと言えます。

そもそも認証基盤を作るのが簡単になる

認証基盤は、単純に作るだけでも非常に大変な面が多いです。 すぐに思いつくだけでも下記の様に色々と出てきます。

• 大量の入力項目
• データのバリデーション
• ユーザーの重複チェック
• 大体似たようなサインアップサインイン画面
• セキュリティ担保
• アクセスの履歴管理
• ユーザー管理画面
• どう作っても大体似ているが、微妙に違う。共通化も結構大変。

また作った後にも修正を行う必要があった場合どうでしょうか。 自前で作っている場合は、下記のような事を行う必要があります。

• 画面に項目追加
• デザイン調整
• DB定義の修正
• DBのモデル修正
• ViewModelの修正
• DBへの書き込み処理修正
• DBからの取得処理修正

これが IDaaS を使った場合は、どうでしょうか。

• 画面に項目追加
• デザイン調整

大幅に作業が減りました。 このように IDaaS 側で様々な作業を吸収できるというのは、非常に大きなメリットではないでしょうか。

AAD B2Cのメリット

• シングルサインオン
• 関連アプリに一貫したUXを提供
• 関連アプリを一か所で管理(アクセス管理、ユーザーメトリック)
• データに対してコンプライアンスポリシーの適用(セキュアに作れる)

AAD B2C の料金体系

AAD B2C は、課金体系に MAU (Monthly Active Users) を採用しています。

以前は、MAU + ユーザ数課金でしたが、ユーザ数課金が廃止され純粋な MAU になりました。

料金体系は、単純明快です。

これに合わせて、MFA を使用した場合は、別途料金が掛かります。

MFA

MFA は、SMS を使用可能です。

ポータルの画面上からは、FIDO、Microsoft Authenticator App を使用するオプションが提供されていますが、2020/11/02 SMS 以外は、上手く機能しませんでした。

Authenticator を使用したい場合は、Identity Experience Framework を使用してがっつり作りこむ必要があります。

競合サービスとの比較

競合の料金体系を一部抜粋して掲載します。 概ね、AAD B2C の方が安い計算になります。

Cognito

Auth 0

Auth 0 に関しては、SLA が提供される運用環境用の Enterprise に関しては、料金体系が公表されていません。

どういった案件に向いているか

今まで色々説明してきましたが、実際どのような案件やサービスに向いているかを考えてみましょう。

AAD B2C は、名前の通り B to C を想定したサービスになります。 そのため、所謂会員管理が必要な EC であったり、スマートフォンのアプリのような広くコンシューマが使用するサービスをターゲットとすることが多いと思われます。(もちろん社内向けのアプリケーションも構築可能です)

ユーザ登録、ログインなどの基本的な機能や画面のカスタマイズ、メール文面のカスタマイズといった部分に関しては、全て独自にカスタマイズが可能なので、大抵のサービスの要件は、満たすことが出来ると思われます。

注意点として、2020年10月現在では、独自のカスタムドメインを設定できないためカスタムドメインが必ず必要で合ったりといった要件には、対応できません。 カスタムドメインを使用できるようにする変更は、現在対応中とのことなので是非皆さん投票しましょう(リンク貼る)

Identity Server

Identity Server とは、.NET Core 向けの OIDC フレームワークです。 .NET Core のアプリケーションに OIDC サーバの機能を追加するためのミドルウェアとして提供されています。 Identity Server を使用すれば、自由にカスタマイズの出来る OIDC サーバを構築することが可能です。

これを使用する場合、自由な実装が可能ですが、インフラの管理などの非機能要件を検討する必要があったり、 フレームワークのアップデートに追従していかないと、脆弱性が放置されたりと、実装・運用双方にコストが掛かります。

Identity Server の情報は、下記のリンクから参照頂けます。

IdentityServer.io

構成例

今回の最後に、AAD B2C で作れる構成例を説明します。 実案件でよくありそうなパターンを 3種類ほど紹介します。

構成例1

最もシンプルな構成図です。

Web アプリケーションの認証基盤として、AAD B2C を使用するという構成です。 この構成では、図の Web アプリ内には、サインイン・サインアップの機能を持たせず、AAD B2C 側でそれぞれを行った上で、認証結果の結果とユーザ情報だけを受け取るシンプルな構成です。 この構成を取ると、アプリケーションを極力改変せずに、セキュアな認証機能を実装することが可能です。

構成例2

外部ユーザーストアを使用した構成図です。

AAD B2C で認証する際に、REST API を経由して外部のデータストア(Dynamics、Salesforce のような CRM、既存のユーザストアなど)から足りない情報を取得し、 アプリケーションに返すユーザ情報に外部のデータストアの情報を付与してデータを返す構成になっています。

AAD B2C は、認証フローの途中で任意の REST API を呼び出すことが可能なため、実現できる構成です。

この構成を取ることによって、既存のデータストアを全て AAD B2C に移行することなく AAD B2C のメリットを享受出来ます。

構成例3

AAD B2C は、メールアドレス認証や登録完了時などにメールを送信する部分が存在します。 ですが、デフォルトのメール文面は、内容が簡素であったり、Microsoft から送信されているという旨の記載があったりと サービスの世界観と合わせることが難しい文面になっています。

そこで、メールをカスタマイズしたい場合は、メール送信機能を外部のメールプロバイダに変更して自由にメールの文面をカスタマイズ出来る構成を取る必要があります。 外部のメールプロバイダを使用する場合は、自由にメール文面のカスタマイズが出来るので、サービスの世界観を壊さずにフローを構築できます。

注意点として、使用できるメールプロバイダは、REST API でメール送信する機能が存在するものに限ります。(SendGrid など)

まとめ

本記事では、AAD B2C の基本的なことについて説明しました。 次の記事以降で、具体的に AAD B2C による認証システムの構築方法を説明していきます。

ユーザーフローに続きます。