Auth0導入で後悔しないための設計ガイド
最近、新旧のプロダクトで分散するAuth0のテナントを再整理したため、新規導入時やテナントの統廃合にあたって色々判断するときのポイントやハマりどころを残しておきます。
Auth0は何も考えないでサクッと導入することもできますが、そうすると後で何も考えたくなくなるほど後悔するのもまた運命です。
つらい・・・。
テナントを分ける境界を考える
まずは全ての基本となるテナントの設計を考えます。
テナントを追加していくときに、どういった単位でテナントを作成するのか？という観点や方針がバラバラだと後で辛いです。
究極的には1つでも可能です。ただし後で災いが降り掛かってきますが・・・。
なぜ分割する？
一番大きな理由は、カスタムドメイン、Universal Login、メールテンプレート等のブランディングに関する部分や、その他にもMFA、Orgazanitionなどテナント全体に影響する設定を統一するのが難しい（ことが多い）ためです。
特に複数のプロダクトでAuth0を利用する場合に当てはまります。
トリガーやアクションなど複雑なユースケースに対応するための機能は提供されていますが、分離したほうがよりシンプルですし、そういったところで無理に頑張るとあとで負債になって帰ってくることも多いので、どうしても1つにしたい理由がなければ素直に分割したほうが良いと思います。
ただ逆にそういった部分が解決できたり、そもそも障壁にならない場合は、1つの方が共通の認証基盤としてまとめられるので良いかもしれません。（開発と本番は流石に分けたほうが良いと思いますが）
ちなみにコスト的には各テナントのMAUの合算のはずなので特にどちらでも変わりません。
どう分割する？
色々観点はあると思いますが、個人的には
- 用途ごとに開発用・本番用・テスト用で分ける
- 各デプロイ環境用の設定はApplicationやConnectionで分ける
のが一番バランスがよいと感じました。
例えばdev, staging, prodに加え、各チームが占有する環境がA～Bの2つあるとします。
この場合 dev, チームA, チームB は開発用のテナントに、prodは本番環境用のテナントにそれぞれAuth0のApplicationを作成します。
（図の例では、stagingは認証周りに関してはProdと同一にするものと仮定してProdに繋いでいます）
こうすることで、テナント全体の設定は共通になりますが、各アプリケーション固有の設定は分離することができますし、接続するConnectionだけ共通にして開発環境全体で共通のユーザとしたり、Connectionも分離して各環境のユーザを完全に独立させることもできます。
テスト用は基本的にAuth0の設定やそこから先のOIDCやOAuthサーバとの連携を検証したりするのに使うため、例えばローカルや各チームの環境に繋ぐためにApplicationやConnectionなど好きに作って必要に応じて繋ぎ変えます。
デフォルトのものは消しておく
現時点ではAuth0のテナントを作成すると、自動的にApplication、DB Connection、Social Connection（Google）が1つずつ作成されます。
これが少し厄介で、これらの設定が残っている場合、新しくApplicationやConnectionを作成したときに自動的にデフォルトのものと紐づいてしまいます。
セキュリティ的な問題もそうですが、Terraform等API経由で設定を投入する場合に処理が重くなってタイムアウトしたりすることもあるので、できればテナント作成時に消しておきましょう。
MFAの注意
Auth0ではいくつかの方法でMFAを設定することができますが、ユーザのデバイス要件次第では少し注意が必要です。
特にMAFでパスキーを導入する場合です。
WebAuthnにおける Authenticatorの種類
そもそもパスキーの根幹をなすWebAuthnの認証器には、Roaming Authenticator と Platform Authenticator の2種類が存在します。
Roaming Authenticator と Platform Authenticator
簡単に説明すると、外部の認証器（NFC、USB、Bluetoothなどで接続して認証する）か、デバイスに組み込まれた認証器（FaceID、WindowsHello、指紋認証など）かという違いです。
前者はYubiKeyなんかの物理セキュリティキーや、最近はスマホなどのhybrid transport（デバイス内蔵の認証器を別のデバイスから利用する仕組み）に対応した機器が該当し、後者はスマホやPCに内蔵された指紋認証や顔認証が該当します。
詳しくは以下の記事が参考になります。
そして、Auth0ではそれらを WebAuthn with FIDO Security Keys と WebAuthn with FIDO Device Biometrics という設定で制御することができます。
設定の条件
Auth0ではMFAに設定する認証手段をいくつかの種類に分類しており、それらの組み合わせで最低限必要な認証手段を設定する必要があります。
例えばAuth0のMFAでは前述した2種類の設定でパスキーを導入することが出来ますが、Webauthn with FIDO Device Biometricsのみをオンにすることはできません。
デバイスの組み込み認証器を唯一の手段とすると、デバイスを紛失したときなどに回復する手段がないためです。
Given platform authenticators can only be used in a single device, it should not be the only factors that users enroll. To make sure users are not locked out from their accounts, Auth0 will prompt users to enroll with platform authenticators after they succesfuly authenticated using another authentication method.
このようにAuth0では 依存性要素（Dependent Factors） という、それ単体では認証手段として設定することの出来ない認証手段が定義されており、以下の3つが該当します。
- Webauthn with FIDO Device Biometrics
- Recovery Code
そのため、これらの種類の認証手段を設定する場合は、別途Independent factorsと呼ばれる種類の認証手段と組み合わせて設定する必要があります。
カスタムメールプロパイダーは必須
Auth0でEmail verifyやパスワードリセットなどを利用できるようにする場合、カスタムメールプロバイダーを設定する必要があります。
設定しない場合、デフォルトのテスト用メールプロバイダーが利用出来ますが、Auth0いわく本番環境での運用は保証しないこと、加えてリミットとして1分あたり10件までの送信に限られるといった制限があります。
そのため、本番環境で利用する場合はAmazon SESやsendgridいったメールプロバイダの設定が必須です。
APIのRate Limitとキャッシュ
Auth0にはManagement APIとAuthentication APIの2種類が存在します。
どちらも当然Rate Limitが設けられています。
基本的にはユーザ側から頻繁に叩くような用途ではなく、あまり大規模な利用に耐えられるような回数ではありませんので（プランにもよりますが）、瞬間的にアクセスが集中するようなプロダクトでは適切にキャッシュするなどしてAPIのリクエストを減らす事を考えます。
例えば氏名やemail、電話番号といったよく使用される情報などはid_tokenに含まれる（あるいは含める事が可能な）ため、userinfoエンドポイントなどを叩くことはせず初回のログイン時にキャッシュすることで無駄なAPI呼び出しを避けるといったことが必要です。
RateLimitの複雑さを回避する
metadataのサイズと検索
Auth0ではユーザに付随する情報としてuser_metadataとapp_metadataが用意されています。
保存可能サイズについては、2023年時点でのコミュニティの質問では、Auth0側の回答としてユーザごとに最大16MBが保存できると回答しており、参照元としてドキュメントを引用しているようですが、2025年3月時点では同ページにそのような記載はないようです。
そのため現時点ではドキュメントから正確なリミットは読み取れませんでした。
もしかしたらTAMなどのサポートに問い合わせるとわかるかもしれません。
ただどちらにしろ1MBを超えるメタデータについてはインデックスされず、ユーザ検索APIで返却されない仕様であるため、metadataとして保存するデータに関しても適切に設計する必要があります。
（検索は出来なくても直接ユーザを指定して取得することは可能です）
Discussion