\ 積極採用中 / @xhiroga（小笠原寛明） justInCase Technologies, Inc. マルチテナントSaaSのカスタム要件に、 Auth0テナントを分割せず向き合う！ Okta Study Meetup #4 「Auth0で実装する認証と認可」@ 2022-08-10

\ 採用中 / 目次 ● ごあいさつ ● なぜマルチテナントなのか ● なぜAuth0なのか ● カスタム要件にAuth0テナントを分割せず向き合う ○ 認証のカスタム要件 ○ セキュリティのカスタム要件 ○ 画面のカスタム要件 ○ 開発と運用 ● まとめ ● おしらせ 1

\ 採用中 / ごあいさつ 自己紹介 2

\ 全職種採用中 / 3

\ 採用中 / ごあいさつ 日本初の商品を連発している保険会社です。 4

\ 採用中 / ごあいさつ そのノウハウを元に保険SaaSを提供しています。 5 顧客 保険会社* *事業会社や保険代理店 のご利用も可能 プラン選択 本人認証 告知・重要事項説明 会員資格確認 商品ページ(LP) ＆ 申込フォーム 契約参照 異動・解約 決済 契約更新 お客様 ポータル 査定・承認 問合せ 提出書類の参照 （電子データ） 支払記録 保険金 請求フォーム

\ 採用中 / 会社紹介 保険業務をSaaSでなめらかにし、みなさんがよい保険にアクセスしやすいようにしています。 6

\ あなたと一緒に働きたい！ / なぜマルチテナントなのか

\ 採用中 / なぜマルチテナントなのか 規模によらず、様々な保険会社のお客様に ご利用いただくため 8

\ あなたと一緒に働きたい！ / なぜAuth0なのか

\ 採用中 / なぜAuth0なのか マルチテナントとは、リクエスト単位でアプリケーションを分割すること 10 {tenant_id: justincase} API DB token なるほど、 justinacaseテナントとして 起動すればいいのか！

\ 採用中 / なぜAuth0なのか マイクロサービスでは、ID管理サービスには複数のアクセスがある 11 マイクロサービス1 マイクロサービス2 ID管理サービス token トークン検証 複数のサービスが ID管理サービスにアクセス

\ 採用中 / なぜAuth0なのか 開発が大変 12 OAuth, OIDC準拠が大変 ログイン画面の開発が大変 MFA・IP制限などが大変

\ 採用中 / なぜAuth0なのか エンタープライズに耐えうるIDaaSを比較した 13 参考: 髙栁怜士. “認証サービスCognito・Auth0・Firebaseを比べる” https://techbookfest.org/product/6354233804718080. Pros Cons Auth0 ドキュメント・SDK・ログイン画面が優れている。 リージョンで日本を指定できる 他の選択肢に比べてコストが高い Amazon Cognito UserPool 東京リージョンを指定できる、安価 歴史的経緯もありドキュメントが分かりづらい Google Identity Platform 安価 リージョンを指定できない Firebase Authentication 安価 リージョンを指定できない

\ 採用中 / なぜAuth0なのか 開発者体験が良い 14 ● Auth0を触れる（※1）メンバーの数 ○ 2ヶ月で4名→10名（以上！）に増加！ ○ うちSREは3名のみ、ほかはフロントエンド、PdM、バックエンド ● Auth0に関するチケット ○ スクラムのあるスプリントでは、15枚のチケットを6名以上で分担！ ● Auth0のサポート ○ 体感で2日程度で返答、日本語でサポート頂ける場合も！

\ あなたと一緒に働きたい！ / 認証のカスタム要件

\ 採用中 / 認証のカスタム要件 保険会社によって要件が異なる 16 ● パスワードに含まれるべき文字の種類 ● パスワードの長さ ● パスワードの再利用の可否 ● パスワードにメールアドレスなどと同じ文字列が含まれてよいか ● LINEログインなどのソーシャルログインの有無 ● Azure ADなどのSSOの有無 ● セッションの長さ ● IP制限 ● MFAの有無 ● MFAの手段 ● etc…

\ 採用中 / 認証のカスタム要件 Auth0におけるマルチテナントの実装方法 17 分け方 Pros Cons Auth0テナントで分ける ダッシュボードへの直アクセスを含む、テナ ントの要件に柔軟に対応可能 運用コストがかかりすぎる Auth0 Organizationで分ける toBであれば便利 toCには使えない Auth0 Applicationで分ける Branding対応などを見るに公式推奨 運用コストがややかかる DB Connectionで分ける 同じメールアドレスでテナントごとに別ユー ザーを作成できる DB Connectionにはメタデータがない User Metadataで分ける 最も作成するリソースが少ない カスタムの幅が限られる

\ 採用中 / （意訳） Auth0は、企業間取引（B2B）のお客様がパートナーや顧客をより適切に管理し、エンドユーザーが自社のアプリケーショ ンにアクセスする方法をカスタマイズできるようにするため、Auth0プラットフォームの幅広いアップデートを実施しました。 Auth0のお客様は、Organizationを利用して以下のことが可能です。 ● 顧客やパートナーをAuth0に登録し、その所属や権限などを管理する。 ● ビジネスごとに異なるロゴや色を使ってログインフローをブランディングできる。 ● Organizations APIを使用して、自社製品に管理機能を組み込み、企業が自社組織を管理できるようにする。 認証のカスタム要件 Organizationとは 18 参考: Auth0, Inc. “Auth0 Organizations” https://auth0.com/docs/manage-users/organizations

\ 採用中 / 認証のカスタム要件 Organizationへの（個人的な）誤解 19 △複数テナント所属を可能にする機能 Organization登場以前、テナントごとにAuth0 Applicationを分ける設計が一般的。 → 1ユーザーが複数テナントに所属できない。 参考: urmot. “Auth0 Organizationsという素晴らしい機能を今更ながら紹介する .” Zenn. https://zenn.dev/urmot/articles/8c18d8b49d822c 加藤. “B2BマルチテナントSaaSの認証にAuth0を使うときに知っておきたかったこと ”. Sansan Tech Blog. https://buildersbox.corp-sansan.com/entry/2020/04/22/110000 ◎それ以外にもB2Bの便利機能がたくさん！ ● 複数テナントに所属できる ● セルフサインアップを無効に ● Eメールでの招待 ● アクセストークンにOrganizationId ● Organization単位のメタデータ ● Organization単位のロゴ・色

\ 採用中 / 認証のカスタム要件 最終的なアーキテクチャ 20 マイページ （toC） 管理画面 （toB） Application Application テナント別に DB Connection toCとtoBで テナントを分ける

\ あなたと一緒に働きたい！ / セキュリティのカスタム要件

\ 採用中 / セキュリティのカスタム要件 【再掲】保険会社によって要件が異なる 22 ● パスワードに含まれるべき文字の種類 ● パスワードの長さ ● パスワードの再利用の可否 ● パスワードにメールアドレスなどと同じ文字列が含まれてよいか ● LINEログインなどのソーシャルログインの有無 ● Azure ADなどのSSOの有無 ● セッションの長さ ● IP制限 ● MFAの有無 ● MFAの手段 ● etc…

\ 採用中 / セキュリティのカスタム要件 【再掲】保険会社によって要件が異なる 23 ● パスワードに含まれるべき文字の種類 ● パスワードの長さ ● パスワードの再利用の可否 ● パスワードにメールアドレスなどと同じ文字列が含まれてよいか ● LINEログインなどのソーシャルログインの有無 ● Azure ADなどのSSOの有無 ● セッションの長さ ● IP制限 ● MFAの有無 ● MFAの手段 ● etc… Actionで対応可能！

\ 採用中 / ◎Actionのメリット ● ドラッグ＆ドロップで分かりやすい設定 ● インターネット上のnpmのパッケージが使える ● エディタが高性能、型から予測変換表示も ● バージョン管理 ● etc… セキュリティのカスタム要件 RuleではなくActionを使おう 24 Rules Hooks Actions 参考: Auth0, Inc. “Introducing Auth0 Actions”. Auth0. https://auth0.com/blog/introducing-auth0-actions/

\ 採用中 / exports.onExecutePostLogin = async (event, api) => { console.log('onExecutePostLogin'); const { user } = event; if (user.email_verified) { return; } const ManagementClient = require('auth0').ManagementClient; const management = new ManagementClient({ domain: event.secrets.domain, clientId: event.secrets.clientId, clientSecret: event.secrets.clientSecret, }); const { SESClient, SendEmailCommand } = require('@aws-sdk/client-ses'); // 以下省略 セキュリティのカスタム要件 Actionの実例 25 npmのパッケージが使えるので、 AWSと直接接続することも可能！

\ 採用中 / セキュリティのカスタム要件 制約も存在する 26 ● パスワードに含まれるべき文字の種類 ● パスワードの長さ ● パスワードの再利用の可否 ● パスワードにメールアドレスなどと同じ文字列が含まれてよいか ● LINEログインなどのソーシャルログインの有無 ● Azure ADなどのSSOの有無 ● セッションの長さ ● IP制限 ● MFAの有無 ● MFAの手段 ● etc… どれを優先的に使うかは設定不可。 （複数のMFAの手段があった場合どれを使うかは Auth0に 任せるべきというポリシーと推察 ...せめてOrganization単 位で有効化の設定をさせて〜！）

\ あなたと一緒に働きたい！ / 画面のカスタム要件

\ 採用中 / 画面のカスタム要件 サインアップ画面に利用規約を表示したいだって！？ 28 ここに 「利用規約」 「プライバシーポリシー」 を表示したいって...！？

\ 採用中 / 画面のカスタム要件 ULPのカスタマイズへの勘違い 29 HTMLをカスタマイズできる が...Classic ULPしか編集できな い！

\ 採用中 / 画面のカスタム要件 New ULPを使おう！ （意訳） Auth0の新しいユニバーサルログインエクスペリエンスは、新鮮なUXデザインと軽量なページで、ログインフローを再構築 しています。この新しいエクスペリエンスを選択すると、Auth0はカスタマイズされていないすべてのページでこのエクスペ リエンスを使用します。ダッシュボードのブランディング > ユニバーサルログイン設定タブで有効にすることができます。 30

\ 採用中 / {% if transaction.params.ext-disableSignup == "true" and prompt.name == "login" %} document .querySelectorAll('a') .forEach( (link) => link.innerText === '{{ prompt.screen.texts.footerLinkText }}' && link.parentElement.remove(), ); {% endif %} 画面のカスタム要件 勝手に改造 31 改造の例: ログイン画面を表示中 かつ パラメータ disableSignup が true なら サインアップボタンを表示しない ※Auth0サポート対象外

\ あなたと一緒に働きたい！ / 開発と運用

\ 採用中 / 開発と運用 ユーザーにテナントを選ばせたくない 33 前画面の入力を元に テナントを識別 サブドメインなどを元に テナントを識別

\ 採用中 / 環境変数で静的に設定 開発と運用 動的にAuth0の設定を変えよう 34 URLを見て動的に設定

\ 採用中 / 開発と運用 実は nextjs-auth0 が使いたかった 35 nextjs-auth0はフロントエンドでアクセ ストークンを持たず、よりセキュア。 ただし動的にAuth0Settingを行うこと はできない...

\ あなたと一緒に働きたい！ / まとめ

\ 採用中 / まとめ Auth0を使うことで、マルチテナントのカスタム要件を運用しやすい方法で実現できた！ 37 ● チームメンバーのキャッチアップが容易 ● DB Connectionを分けることで認証のカスタマイズが可能 ● Actionを利用することでセキュリティ面のカスタマイズが可能 ● ULPのテンプレートを編集することでログイン画面のカスタマイズが可能

\ あなたと一緒に働きたい！ / おしらせ

\ 採用中 / おしらせ 採用中です！ 39

\ 採用中 / おしらせ 書籍化します！ 40 今日しなかった マルチテナント以外の話も 満載！

\ あなたと一緒に働きたい！ / EOL