35
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ID管理と認証(Authn)技術の選定【マルチテナントSaaSにおけるエンジニアリング大全 Day5】

Last updated at Posted at 2025-12-04

Day5_rev1.jpg

はじめに

本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day5 の記事です。弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。

今回からはデータ分離の話とはやや異なり、テナントのユーザ管理の核となるトピックである「ID管理」と「認証」について取り扱います。

B2B SaaSのマルチテナントにおける認証の複雑性

さて、ID管理、認証については、小さなプロジェクトや個人開発においては、 Firebase AuthenticationやSupabaseなどを選定すればそれで十分こと足りることが多いです。 しかしながらマルチテナントSaaSにおいては、要件を満たすことが難しい場合があります。認証時に「誰であるか」を確認するだけでなく、「どのテナントに所属しているか」も同時に管理する必要があることに起因します。

これは具体例を出したうえでの複雑性を理解していただく方が良いと思うので、弊社Qastでの事例をまずは紹介します。

  • メールアドレス/パスワード認証
    • 企業のメールアドレスと各自が設定したパスワードでログインする機能
  • ID/パスワード認証
    • メールアドレスを所持していない社員向けにIDを付与してログインする機能
  • SAML認証(シングルサインオン)
    • SAML2.0により各IdPによるシングルサインオンが可能な機能
    • AD連携(SCIM)によるプロビジョニングも可能
  • MFA(多要素認証)
    • ワンタイムパスワードによる認証を追加で設定可能
  • 外部APIによる認証
    • QastのAPIをアクセストークンを利用して呼び出すことが可能

さらに、アプリケーションで全テナント一律で設定できるものではなく、各社ごとのポリシーを設定することができるため、認証を企業ごとに切り替える必要があります。

テナントごとに認証方式を設定可能にし、管理者が自社に適した方法を選択できるようにします。同一テナント内でも複数の認証方式を併用できるようにし、正社員はSSO、派遣社員はID/パスワードといった使い分けを可能にします。この要件に対応しようとすると認証基盤の複雑性は急速に増大します。

「ID管理」と「認証」は非常に密接で、採用する認証方式が ID 管理の設計全般に影響します。例えば、SAMLを使うテナントではXML属性の処理が必要になり、OIDCを使うテナントではJWTの処理が必要になります。テナントごとに選択された認証方式が、後続のプロビジョニング、属性マッピング、ポリシー適用といったID管理の設計に全般に大きく影響します。

IDaaS vs 内製

さて、ID管理や認証技術自体の話はここではしませんが、技術選定をするときに、マネージドのサービスを利用するか、自前で開発するかといった観点で、大きく分かれるでしょう。

IDaaSはいくつかのサービスがありますが、マルチテナントSaaSで採用されるフルマネージドのIDaaS代表格であるAuth0が紹介する記事が非常に詳しいので引用させてください。

auth0.pnghttps://auth0.com/blog/using-auth0-for-b2b-multi-and-single-tenant-saas-solutions/

Auth0の例では、Auth0にID管理や認証機能を委任することで、それらを実現する方法を提供しています。テナントごとに設定を変更できるほか、Auth0が管理するあらゆる認証方式から、大企業においては必須のAD連携までを自前で実装する必要がないため、実装コストを軽減したい初期フェーズにおいては非常に強力なメリットになります。

しかしながら、Auth0のようなリッチな仕組みは、スケールとともにコストが肥大化するという強烈なデメリットをはらんでいます。実装フェーズによってとるべき選択肢も変わりますが、将来的なスケールとのトレードオフとなるでしょう。

IDaaS + 内製の認証基盤を取り入れる

さて最近はマルチテナントSaaSかはさておき、認証基盤の内製の事例も非常に多くなってきました。特にコスト観点でスケールするにしたがって内製化を試みたというパターンも多く見聞きするようになったと思います。

とはいえ、認証機能を自前実装することはセキュリティリスクも高いため、全てを内製化するという選択肢とも限らず、OIDC Providerを外部サービスに委託しつつ、テナント管理やカスタムポリシー適用といった上位層の機能のみ内製するというハイブリッドアプローチを採用する事例も増えています。

この背景には、認証認可プロトコルであるOIDCの成熟に伴い、 Ory Hydraなどの認可OSS、AWS Cognitoなどのマネージドサービスの実用性の向上が大きく寄与しているような気がしています。 また、ビジネス的な観点ではマルチプロダクトに展開する企業も増えたことで、複数プロダクトでID管理は一つで管理したいというニーズも高まったことによります。

まとめ

マルチテナントSaaSにおける認証は最終的に複雑化しやすいため、最初から完璧さを追求するのではなく、ビジネスの成長に応じて進化させられる柔軟な仕組みを目指すことが重要でしょう。

さて、次回のDay6では、認証の次のステップとして、認可(Authorization)とアクセス制御の設計について解説します。お楽しみに!

35
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
35
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?