テナントごとに異なる統制とどう向き合うか ログラスのマルチプロダクトを ⽀える認証基盤 2026年9⽉30⽇｜SaaS Harbor 株式会社ログラス 村⼭ ⼤貴 

⾃⼰紹介 村⼭ ⼤貴 Daiki Murayama 株式会社ログラス 技術本部 技術基盤部 プロダクト基盤チーム / エンジニア トヨタ⾃動⾞で、カーナビ向けミドルウェアの開発に3年ほど携わる フリーでは、認証認可/契約管理基盤の開発から基盤領域の組織マネジメントまでを担当 現在はログラスで、マルチプロダクトを⽀える基盤の設計‧構築などをリード © 2026 Loglass Inc. 2 

No content

No content

No content

目次 01 マルチテナント SaaS に求められること 02 3つの選択肢と選んだ理由 03 Step-up 認証による実現 © 2026 Loglass Inc. 6 

01．マルチテナント SaaS に求められること © 2026 Loglass Inc. 7 

01 マルチテナント SaaS に求められること グループ会社では、会社（テナント）ごとに求める認証統制が違う 顧客グループ Loglass ⼦会社 X IdP B（例: Okta） ⼦会社 X テナント IdP B で SAML @group.example 1 SAML 必須（IdP B） 社員 2 3 親会社 IdP A で SAML @group.example IdP A（例: Entra ID） 社員 SAML必須（IdP A） 経営企画 ⼦会社 Y パスワード + MFA @y.example（別ドメイン） IdP なし 1 同じドメインでも IdP が違う 親会社テナント ⼦会社 Y テナント パスワード 社員 2 1⼈が複数テナントに所属する IP 制限 MFA 必須 3 統制要件もテナントごとに違う IdP（Identity Provider）：社員のアカウントと認証を会社で⼀元管理し、SSO で各サービスへのログインを統制するサービス © 2026 Loglass Inc. 8 

01 マルチテナント SaaS に求められること SAML 必須のテナントには、IdP アカウントを持たない委託先も参加する Loglass パスワードで⼊りたい 親会社テナント 委託先‧監査法⼈ 顧客 IdP にアカウントなし SAML 必須（IdP A） IdP A で SAML 親会社の社員 ⼦会社 X テナント IdP B で SAML SAML 必須（IdP B） ⼦会社 X の社員 © 2026 Loglass Inc. 9 

01 マルチテナント SaaS に求められること テナントの統制を守ったうえで、以下の項⽬に応える必要がある 1 テナント統制 テナントが決めた SAML 必須‧IP 制限‧MFA を、必ず守れるか 2 外部ユーザ IdP にアカウントのない⼈を、統制を崩さずに⼊れられるか 3 ログインUX 複数テナントに所属する⼈が、ログインし直さずにテナントを移れるか 4 運⽤コスト 会社が増えても、ログインの⼊⼝や設定が増え続けないか 5 内部コスト IDaaS の課⾦対象となるアクティブユーザーが、想定以上に増えないか © 2026 Loglass Inc. 10 

02．3つの選択肢と選んだ理由 © 2026 Loglass Inc. 11 

02 3つの選択肢と選んだ理由 テナントごとの違いをユーザーにどう⾒せるかで、体験は3通りある A テナントごとのログイン画⾯を持たせる（これまでの選択） B テナントごとに別のアカウントを発⾏する C テナントに対して不⾜した認証を都度求める グループ会社で異なるIdPを利⽤する場合には、専⽤のログイン画⾯を⽤意する テナントごとにアカウントを作り、それぞれの画⾯でログインする 共通のログイン画⾯から⼊り、SAML 必須のテナントに⼊るときだけ追加で認証する © 2026 Loglass Inc. 12 

02 3つの選択肢と選んだ理由 A) 元々は、Auth0 がメールドメインで IdP を振り分ける構成だった 各プロダクト（FE + BE） Auth0 Universal Login 経営管理 Post-Login Actions OIDC / JWKS ユーザー（所属テナントの情報も保持） HTTPS 顧客 IdP A ⼈員計画 SAML connection ユーザー Home Realm Discovery で振り分け AI IR 顧客 IdP B SAML 連携（信頼関係） Management API ほか gRPC 内部テナント管理サービス テナント‧ユーザー管理だけを切り出して共通化 HRD（Home Realm Discovery）：ログイン時に、メールアドレスのドメインから使う IdP を選ぶ Auth0 の機能 © 2026 Loglass Inc. 13 

02 3つの選択肢と選んだ理由 A) HRD は、1つのドメインに1つの IdP しか割り当てられない ✓ SAML connection IdP A 親会社テナント Home Realm Discovery （HRD） IdP A で⼊るしかない メールドメイン [email protected] group.example ✕ ✕ 1ドメイン＝1 connection SAML connection IdP B ⼦会社 X テナント （IdP B で⼊りたい） 同じドメインには割り当てられない © 2026 Loglass Inc. 14 

02 3つの選択肢と選んだ理由 A) ⼀時的に会社専⽤のログイン画⾯を作成し 、複数での IdP に対応 親会社のテナントへ 共通ログイン画⾯ Home Realm Discovery IdP A メールドメインで振り分け taro ⼦会社 X のテナントへ 親会社の経営企画 専⽤のログイン URL 組織を指定 IdP B Auth0 の組織を指定して IdP に直⾏ • 同じ taro さんでも、親会社は共通のログイン画⾯、⼦会社 X は専⽤のログイン URL から⼊る • ログインした画⾯で IdP が決まるため、IdP の違うテナントへはログインし直さないと移れない © 2026 Loglass Inc. 15 

02 3つの選択肢と選んだ理由 B) テナントごとにアカウントを分けると、様々な⼿間が発⽣する 親会社テナント⽤のアカウント SAML (IdP A) ⼦会社 X テナント⽤のアカウント taro 1 テナントを移るたびに ログインし直す必要がある 2 アカウントの発⾏と管理が テナントの数だけ要る 3 アクティブユーザーが 所属の数だけ増える SAML (IdP B) 親会社の経営企画 ⼦会社 Y テナント⽤のアカウント パスワード + MFA © 2026 Loglass Inc. 16 

02 3つの選択肢と選んだ理由 C) 1つのアカウントのまま、テナントに対して不⾜した認証だけ追加で求める 親会社テナント ✓ 使える SAML 必須（IdP A） 共通のログイン画⾯ taro 親会社の経営企画 IdP A で1回ログイン ⼦会社 X テナント SAML 必須（IdP B） IdP B の認証だけ 追加で求められる ✓ © 2026 Loglass Inc. 使える 17 

02 3つの選択肢と選んだ理由 Cであれば、 テナントの統制を守ったうえで、各要求に応えられる A 会社ごとの B テナントごとに C テナントに対して ログイン画⾯（これまで） アカウントを分ける 不⾜した認証だけ求める 認証統制 △ 画⾯ごとにしか決められない 外部ユーザ × このニーズに対応できなかった ログインUX × テナントを移るたびにログイン × テナントを移るたびにログイン 運⽤コスト × 会社ごとに専⽤の画⾯が必要 × テナントごとにアカウントが必要 内部コスト ○ ○ ○ 個別のアカウントで⼊れる × 所属の数だけ増える ○ アクセス先のポリシーで判定 ○ ポリシーに認証⽅式を⾜す ○ ⾜りない認証だけ追加で求める ○ 共通のログイン画⾯1つ ○ © 2026 Loglass Inc. 18 

03．Step-up 認証による実現 © 2026 Loglass Inc. 19 

03 Step-up 認証による実現 アクセスのたびに認証の過不⾜を判定し、⾜りない分だけ求める 判定 テナントへの リクエスト このテナントに必要な認証を 満たしているか 充⾜ リソースに アクセスできる 不⾜ 追加の認証 ⾜りない認証だけ その場で求める 状態の記録 追加で認証したことを セッションに記録 必要な認証はテナントのポリシーで決まり、委託先などにはメンバー単位で認証⽅式を⾜せる © 2026 Loglass Inc. 20 

03 Step-up 認証による実現 追加の認証を求める⽅法は、RFC 9470（Step-up Auth）で標準化されている 前提：クライアントは、通常の認証で取得したアクセストークンにより、普段のリソースを使えている クライアント リソースサーバー（RS） 認可サーバー（AS） ① より強い認証が要るリソースを呼ぶ ② acr / auth_time が⾜りないと判断 ③ 401 Unauthorized WWW-Authenticate: Bearer error="insufficient_user_authentication", acr_values="…" / max_age=… ④ acr_values / max_age を付けて認可リクエスト ⑤ 認証し直し、新しいトークン（acr / auth_time ⼊り）を返す ⑥ 新しいトークンでやり直す（通る） acr（Authentication Context Class Reference）：満たした認証の種類、auth_time：認証した時刻 acr_values：リソースが求める認証の種類、max_age（Maximum Authentication Age）：前回の認証から許容する経過時間（秒） 出典: https://www.rfc-editor.org/rfc/rfc9470.html © 2026 Loglass Inc. 21 

03 Step-up 認証による実現 Loglassでは、API Gateway を介して 認証基盤が判定 する⽅式を選択 各プロダクト API 内部 JWT（アクセス先テナントを1つだけ含む） 経営管理 ⼈員計画 AI IR ほか API Gateway ユーザー 判定 認証基盤 OIDC ユーザー‧所属‧ポリシー 内部 JWT テナントごとの認証状態 Auth0 パスワード認証‧SAML 連携 Mgmt API SAML 連携 判定して内部 JWT を発⾏ 顧客 IdP ログイン‧Step-up のときは、ブラウザのリダイレクトにより、Auth0 経由で顧客 IdP にアクセスする © 2026 Loglass Inc. 22 

03 Step-up 認証による実現 ⾜りない認証があれば、アクセスした時点で Step-up を求める ブラウザ API Gateway 認証基盤 Auth0 ⼦会社 X の IdP ① ⼦会社 X テナントの アクセス ② 判定 ③ acr が⾜りない ④ 401 ⑤ Step-up 開始 ⑥ リダイレクトで SAML 認証（IdP B を指定） ⑦ コード → ID Token ⑧ セッションに記録 ⑨ 元の画⾯へ戻る ⑩ 再リクエスト → 通過 © 2026 Loglass Inc. 23 

まとめ © 2026 Loglass Inc. 24 

まとめ Step-up Auth によって、グループ会社におけるテナント統制と体験を両⽴する マルチテナント SaaS において、グループ会社のケースを考えた際に 1 各会社（テナント）の認証の統制の違いなどを考慮する必要がある テナント間で異なるポリシーを持ち、 2 3 ⾜りない認証だけを Step-up Auth（RFC 9470）で求める⽅式を選択 これにより、テナントごとの認証の統制とユーザ体験の向上を両⽴した © 2026 Loglass Inc. 25 

良い景気を作ろう。 共通基盤エンジニアを募集しています https://hrmos.co/pages/loglass/jobs/Eng-SWE-002 © 2026 Loglass Inc. 26