Auth0
概念
テナント（Tenant）
アプリケーション、ユーザー、コネクションなどの親概念。
テナント：アプリケーションは1:N
1つの契約の中で複数テナントを作ることができる。
アカウント（Account）
人がAuth0の管理開発機能を使うためのアカウント。
テナント：アカウントはN:Nの対応を持つ
Tips
API Debugger Extensionを使うと便利
Application
Regular Web Application
トークン保管：cookie or DB
Native APP
OSの暗号化機構にトークンが保管できる
認証自体は外部ブラウザを使う
UI実装が2種類
ブラウザベース
SSOができる
ネイティブ実装
SSO不可。表示速度は早い。
iOSの場合「サインインのため〜を使用しようとしています」というダイアログが出る仕様。
ブラウザのクッキーにアクセスするタイミングで出る
useEphemeralSession で回避はできる（SSOができなくなる）
SPA
トークンはブラウザのオンメモリ or localStorageに保管
localStorageはXSSで漏洩する可能性がある
Native APPと違ってセキュアなストレージがない。
サードパーティクッキーがブロックされていると、初期ロード時はログインされてないように見える。
M2M（Machine to Machine
ファイルシステム or DBにトークン保管
サーバ間の通信ケース
SSOについて
Auth0ではSSO用クッキーを発行して実現する
Auth0のUniversal Loginで発行される。
Single LogOutはサポートしていない（2022/3時点）
あるアプリでログアウトしたことを他のアプリに伝える仕組みを用意していないため。
ログアウトURLをチェーンして実現するのがよくあるパターン。
Action, Hooks, Rules
拡張系機能のこと
Actions、Hooks
あらかじめ用意されたポイントで処理を挟める。
console.log(...)するとMonitoring > Logs > Action Detailsにログが出たり
同期と非同期がある。
同期の方は、処理が終わらないと次の処理に進まない。
同期の方は、エラーを返すと登録をキャンセルしたりできる。
どちらも最大20秒。
とはいえ同期の方は1秒2秒で終わらないと体験が悪い。
非同期のものは多少時間がかかっても大丈夫。
リトライの仕組みはないので、やりたければ自前で作り込む必要がある。
ユーザーにエラーを返却して「後でやり直してね」のほうがシンプルでオススメ
Rules
Actions, Hooksと似た機能。こちらの方が古い。
Rulesでしかできない操作がある。ここら辺は将来機能拡張予定だとか。
SAML要素のマッピング
SSO情報の取得 とか
今は機能が足りてない所もあるけど、これからはActionsがオススメ。
ドラフト管理、バージョン管理、ログ統合などがある
外部エンドポイントを挟んだりできる。RulesでもできるけどActionsの方はもっと高機能
Connections
認証情報のデータソースのこと
Database Connections
メインの保存先
設定可能
色んなパスワードポリシー
パスワード強度、パスワード履歴（過去n回は使えない）、辞書、
emailとは別にユーザー名を持つか
サインアップ有効・無効
Custom Database
自社DBに接続するケース
「import mode」の設定がある
有効＝Auth0に移行する
無効＝既存DBをそのまま使う
移行方法
自動マイグレーション：既存DBで認証が成功したタイミングでAuth0にデータ、プロフィールを作成するパターン。ダウンタイムなしの移行が可能。
パスワードリセット時もちっと頑張れば可能（仮移行を挟む）
一括インポート：Management API経由のインポート。分かりやすいがデータ量に比例して時間がかかる。Auth0がサポートしないハッシュアルゴリズムで保存していると移行後にパスワードリセットが必要になる。
Social Connections
LinkedInとかFacebookとか
Emailや誕生日など、連携時に要求する情報を設定できる
本番稼働時は各プロバイダからClientIdとClientSecretを取る必要がある
開発時はAuth0開発用のものが使えるので楽ちん
Passwordless
生体認証
Emailワンタイムコード
Emaiマジックリンク
WebAuthn
初回だけはパスワードが必要
OIDC (Enterprise Connection)
2つの方法がある
SAML (Enterprise Connection) Home Realm discovery：メールのドメインを見てSAMLか通常のログインかを切り替える機能。 Login
ログイン画面に種類がある
Embeded Login：利用者側でホストするもの。
Universal Login
Classic：古い仕組み。パスワードレスログインを使うにはこちら。
New：新しい仕組み。パフォーマンスが良く今後も機能追加される。
セキュリティ上の理由でカスタムドメインの利用が必須。
一部文言くらいなら大丈夫だけど、ログインウィジェット自体のカスタマイズはできない。
多言語化
Classicではブラウザの設定をチェックしない。
Newではブラウザ設定をチェックして自動で多言語化される。ui_localesパラメタで明示的に指定も可能。
Application Login URI
Auth0が何らかの理由でログイン画面を表示できない時にフォールバックするURL。設定しておいた方が良い。
stateの有効期限が切れている時などが該当する。
EmailでのMFAはデフォルトでは選択肢として表示されない。
email&passwordの組み合わせでログインするケースにおいて、メールアドレスに認証用のコードを送ることはそこまでセキュリティ強度が上がるものではないという考えから。
パスワードリセット
アカウントが存在しないメアドに対してリセットメールを送ろうとしても「送れました！」と表示される。
攻撃者に情報を与えないため
権限管理
概念
Privilage＝特権。
ユーザーに対する権限管理。サービス管理者がユーザーに対して行動や情報アクセスを許可する。
Permission＝権限
リソースに対する権限管理。
Users - Roles - Permissions - Resource/API
RBACは有効無効を切り替えられる
もちろんアプリケーション側の制御は実装が必要
Auth0のRBAC実装上の制限（2022年現在）
AccessTokenに権限情報を付与するので更新がリアルタイムではない。
AccessTokenがRefreshされたタイミングまで遅延する
階層構造を表現できない。
A店の店長としての権限とB店のバイトとしての権限を兼務する、という表現は不可能。
フラットな概念になる。
RoleやScopeの数の制限がある
1Tenantあたり1000Roleまでとか。
A店の権限とB店の権限を別に定義すれば・・・！とかやってると破綻する
→ 複雑なものは自前で実装した方が良い
RBACを利用しない場合のパターン
自前で権限管理APIを作り、Rules/ActionsでAPIを叩いて結果をAccessTokenに埋め込む
AccessTokenには何も情報を持たせず、Resource Serverにアクセスされる度にサーバ内部で自前で権限管理APIを叩くとか検証処理を入れるとかする FGA
Fine Grained Authorization
開発中の機能。RBACよりすごいらしい
Organization
Auth0のテナント1つで、マルチテナントB向けサービスの認証管理ができる
B2B向けサービスの機能
代理店がログイン画面に独自ロゴを出したりできる
できること
顧客の管理
顧客ごとのログインカスタマイズ
アカウントの招待
ユースケース
Slackぽいログイン体験。
最初にOrganization（＝Workspace）を選択し、そこからIdPを使ってログインする
有効にしてるとAccessTokenにorg_id が入る
API
API Explorer
SDKも色々あるよ
大きく分けて2種類
認証系API
ログイン・ログアウト・パスワード変更したりするやつ
一部はCookieを使う都合上ブラウザでやる必要がある
MFA APIもここに含まれる
複数手段の登録はUniversal Loginではできず、APIを使わないといけない。
リカバリーコードもできる。
でも生の値を再表示はできない。前のを破棄して再生成のみ。
RateLimit: 100call per sec
1回ログインで複数回コールされる点に注意。
1ログイン = 3〜最大5回API callになったりする
なので秒間100回ログインできるわけではない
Management API
Auth0のダッシュボードでできることが全部できるAPI
RateLimit: 1,000call per min and 50 call per sec
認証系より厳しい
RateLimit
よくあるNGケース
Rules/Actionsの中で複数回呼ぶ
AccessTokenの有効期限が短すぎてRefreshされすぎる
バッチ処理で一括処理
回復条件はエンドポイントごとに異なる
バッチなどでRateLimitに当たったら、Sleepしていい感じにリトライすればOK
1,000call per minだと秒あたり16〜17回復するので、4秒待つとBucket 50が満タンになる
Private Cloudだと制限が緩和される
足りなければサポートセンターに依頼するコース
Management APIと認証APIのRateLimitは独立しているが、合算されたハードリミットがある？
Security
主に5機能
総当たり攻撃対策
デフォルトでは10回連続ログイン試行失敗でブロックされる
メールに解除リンクが送信される他、ダッシュボードでも解除可能
ログが残る。特定アカウントの除外もできる
基本はIP x アカウント
なのでIPを変えると再チャレンジできる
Lockout Mode：IPアドレス関係なく、アカウントベースで試行カウントするモード
特定IP攻撃対策
特定IPから攻撃がされてると見做すとそのIPアドレスを丸ごとブロックする
HTTP 429が返る
ログが残る
Management APIでIPブロック状態の確認、ブロック解除ができる
管理者への通知も可能。1時間に1回ペース。
漏洩アカウント検知対策
リスト攻撃はリストを保持して検知してる
ログに残る
2レベル
Breached Password Detection：北米中心でWebから情報収集
Credential Guard：強い版。世界中から専任セキュリティチームが秘密の方法で入手する。
bot攻撃検知対策
Botと思われるものにキャプチャを出せる機能
キャプチャを出さずに評価ログだけ取ることもできる。
キャプチャはシンプル版とGoogle reCAPTCHAを選べる
基本はBot NetのIPベース
Adaptive MFA（リスクベース認証）
総合的なリスク判断でMFAをトリガーする
評価軸
NewDevice
ImpossibleTravel
UntrustedIP
MFA未登録であればメールアドレスにチャレンジコードを送る
Rulesで評価を取得してアレコレすることも可能
MFA未登録なアカウントはRulesでMFA登録を促すとか
初めて利用する端末ではMFAを要求するとか
運用
テナント運用
テナント管理者はMFA有効にする
管理者は招待して増やせる
権限も適宜絞れる
1年とか3年に1回くらい
ManagementAPIで自動化もできる
テナントログの検索・保存
大きく3つやり方がある
Log Stream：オススメ
APIのRate Limitを消費しない
パフォーマンスが良くほぼリアルタイムでログを流せる。
他の方法ではバッチ処理になる
Extension
Management APIで自作
監視、ステータスチェック
基本的にお任せ
大事なことは管理コンソールの通知欄＋メールで通知
機能の非推奨化
メンテナンス
でもPrivate cloudだと出ないよ
インシデントレポートだけはprivateでも出すよ
テナント・ユーザー情報のエクスポート、プロビジョニング
Auth0 Deploy CLI
各種設定のエクスポート・インポートができる
内部的にManagement APIを叩いている＝API rate limitを消費する
インポートはこれまでの設定を上書きしてしまう。
実行前にバックアップ取りましょう
バックアップとしてデイリー or リリース時に実行しておくと良い
最近公式サポートされた
ユーザーのパスワードのエクスポートは、サポートへの確認が必要
トラブルシュート
サポセンでチケット作る
アカウントリンク
Auth0は、デフォルトですべてのIDを別個のものとして扱います。
メアドで登録したプロファイルと、Googleでログインしたプロファイルを紐付ける設定のこと