認証まわりを自前で実装しようとして、途中で手が止まった経験はないでしょうか。
OIDCのフロー自体は理解している。
でも実装を進めると、細かい落とし穴が次々と顔を出してくる。
そして「マルチテナントにしたい」という要件が加わった瞬間に、話が一段ややこしくなります。
Auth0は高い、Cognitoは素朴すぎる、Clerkは制約が気になる——そういう状況でLogtoという選択肢が視野に入ってくるわけですが、「結局どんなプロジェクトに合うのか」がよく分からないまま調べ続けている人も多いはずです。
この記事では、認証基盤の調達判断という切り口で、Logtoを選ぶ状況と選ばない状況を具体的に掘り下げます。
認証を自前で実装しない理由、そして「調達」という発想
OIDCの仕様を読んで「なるほど」と思えるエンジニアでも、実装で詰まるポイントは意外と多いです。
たとえばリフレッシュトークンのローテーション。
仕様上は「古いトークンを使ったらエラーにする」だけに見えますが、実際にはネットワーク遅延でローテーション済みのトークンが再送されるケースをどう扱うか、という問題が出てきます。
セッション失効の伝播も地味に厄介です。
ユーザーがパスワードを変更したとき、既存のアクセストークンをどのタイミングで無効化するか。
トークン失効リストを自前で管理するなら、それ自体がステートフルなストレージを必要とします。
こうした問題は「ライブラリを使えばいい」という反論で片付けられがちです。
たしかに passport.js や jose のようなライブラリはプロトコルの複雑さをかなり吸収してくれます。
ただ、ライブラリが抽象化してくれるのはプロトコルレイヤーだけです。
テナントモデルの設計 と RBACの実装 は、結局自分でやることになります。
マルチテナントになった瞬間に、実装コストは一段跳ね上がります。
テナントごとのデータ分離、ユーザー招待フロー、テナント内ロール管理、監査ログ。
これらをゼロから設計・実装・テストすると、認証まわりだけで数週間から数ヶ月を消費します。
プロダクトの本質的な価値とは関係のない部分に、そのリソースを使うのは正直もったいない。
認証基盤は差別化要因になりにくく、セキュリティリスクは高く、メンテナンスコストは長期にわたります。
「作る」か「調達する」かという判断において、認証基盤は調達側に傾きやすい典型例です。
そしてどのサービスを調達するかが、次の問いになります。
Auth0・Clerk・Cognitoと比べたとき、Logtoはどこに立っているか
Auth0はこの領域の老舗で、機能の成熟度は高いです。
ただし価格がネックになりやすい。
公開されている試算によると、B2C Professionalプランで1万MAU時の年額は約300万円を超えます。
スケールするほど費用が比例増加するMAUベース課金の構造は、成長フェーズのプロダクトにとって予算の見通しを立てにくくします。
Oktaに買収されてからはエンタープライズ寄りの方向性が強まっており、スタートアップや中小規模のプロダクトには少しオーバースペックに感じる場面も増えています。
一方で「安さ」を理由にCognitoを選ぶと、別の問題にぶつかります。
MAUあたりの単価は確かに低く、AWSをすでに使っているチームにとっては導入の摩擦も小さい。
ただ「安いが素朴」という評価が的を射ていて、マルチテナントのテナント分離・RBAC・SSOをCognitoだけで実現しようとすると、User Poolsの設計から自前で組み上げる必要があります。
調達したのに実装コストが残る、という状況になりやすい。
Clerkはどうか。
Next.jsとの相性の良さと開発体験の良さで人気を集めていますが、アーキテクチャがシングルアプリ前提で、サードパーティIdPとしての利用には向いていません。
OIDC準拠の厳密さにも課題があるとされており、エンタープライズ連携で問題が出るケースがあります。
クローズドソースなのでコードを読んで挙動を確認することもできません。
料金面では、100組織を超えるとアクティブ組織ごとに課金される構造があり、マルチテナントSaaSが成長するにつれてコストが読みにくくなります。
Logtoはこれらとは少し違う立ち位置にいます。
OSSとして公開されており（GitHubで9,000スター超）、セルフホストとCloud版の二択を取れます。
OIDC/OAuth 2.1への準拠を重視しており、マルチテナントのOrganizationモデルとRBACが標準で組み込まれています。
課金はMAUベースではなくトークンベースの構造を採用しており、ユーザー数の増加がそのまま費用に直結しにくい設計です。
データ主権 の観点も重要です。
Auth0やClerkはデータの保存先がベンダーのクラウドに固定されます。
Logtoをセルフホストすれば、データは自分のインフラに置けます。
規制要件やデータローカライゼーションが求められる案件では、この違いが決定的になることがあります。
LogtoのアーキテクチャとOrganizationモデルが「標準装備」である意味
Logtoのマルチテナント対応の核心は Organization という概念です。
Slackのワークスペースをイメージすると分かりやすいです。
1ユーザーが複数のOrganizationに同時に所属できて、Organization内でのロールはそれぞれ異なっていい。
でもアイデンティティ（ユーザーの実体）は1つに統合されています。
「Aさんは会社Xではadmin、会社Yではmember」という状態を、ユーザーを二重登録せずに表現できる構造です。
これをゼロから設計しようとすると、どこで詰まるかが見えてきます。
ユーザーテーブルとテナントテーブルの中間に「メンバーシップ」テーブルを置いて、そこにロールを持たせる。
ここまでは比較的すんなり設計できます。
でも「テナントをまたいだロールの継承をどう扱うか」「招待メールのトークン管理をどこに持つか」「テナントごとのSSO設定をどう分離するか」といった問題が積み重なっていきます。
LogtoはRBACを2層で持っています。
Organization RBACはテナント内の操作権限を管理するもので、「このOrg内でメンバーを招待できるか」「設定を変更できるか」といった制御に使います。
API RBACはAPIリソースへのアクセス制御で、「このエンドポイントを叩けるか」をトークンのスコープで制御します。
この2層が分かれていることで、テナント内の権限管理とAPIの保護を独立して設計できます。
SSO（SAML/OIDC）・MFA・ソーシャルログインも追加実装なしで使えます。
SAML連携を自前で実装しようとすると、XMLの署名検証・メタデータの管理・IdP側の設定サポートなど、本業とは関係のない作業が大量に発生します。
LogtoではAdmin Console（ブラウザで操作できるGUI）からSSOの設定を追加できるので、エンタープライズ顧客から「うちのAzure ADでSSOしたい」と言われたときに、実装工数なしで対応できます。
セルフホスト vs Logto Cloud：Docker Composeで立ち上げるまで
セルフホストの最大のメリットは、データを自分のインフラに置けることです。
規制要件・データローカライゼーション・社内ポリシーで「データを外に出せない」という制約がある場合、これは決定的な理由になります。
MAU課金を回避できるのも大きく、ユーザー数が増えても認証基盤のコストが比例増加しないという見通しが立てやすくなります。
ただし運用コストは正直に見ておく必要があります。
LogtoはPostgreSQLとRedisに依存しており、これらの運用・バックアップ・アップグレードは自分たちで面倒を見ることになります。
TLSの証明書管理、Logto本体のバージョンアップ追従、障害時の対応体制も必要です。
運用チームが薄い、あるいはまだプロダクトを検証している段階なら、Logto Cloudから始めるほうが賢明です。
Cloud版には無料枠があり、試すだけなら費用はかかりません。
Dockerさえ入っていれば、ローカルで動かすのは数分で終わります。
# docker-compose.yml
version: '3.9'
services:
postgres:
image: postgres:16
environment:
POSTGRES_DB: logto
POSTGRES_USER: logto
POSTGRES_PASSWORD: logto_password
volumes:
- postgres_data:/var/lib/postgresql/data
logto:
image: svhd/logto:latest
depends_on:
- postgres
ports:
- '3001:3001'
- '3002:3002'
environment:
- DB_URL=postgresql://logto:logto_password@postgres:5432/logto
- TRUST_PROXY_HEADER=1
entrypoint: ['sh', '-c', 'npm run cli db seed -- --swe && npm start']
volumes:
postgres_data:
これを起動して http://localhost:3002 にアクセスすると、Admin Consoleのセットアップ画面が開きます。
アプリケーションの登録・ソーシャルログインの設定・Organizationの作成など、GUIから一通り操作できます。
本番環境に持っていくにはPostgreSQLのバックアップ設定やリバースプロキシの追加が必要ですが、「どんな挙動をするか確認する」段階なら上記で十分です。
実務での判断基準：Logtoを選ぶ状況・踏み止まる状況
Logtoが最もはまるのは、マルチテナントSaaSを新規構築する 場面です。
OrganizationモデルとRBACが標準装備されているので、テナント分離の設計コストを大幅に削減できます。
Auth0のコストに引っかかり始めたタイミングでの乗り換え先としても現実的な選択肢で、セルフホストに切り替えることでMAUベース課金の構造そのものを回避できます。
AIアプリにユーザー認証を足したいが、Auth0ほどの重厚さは不要というケースにも向いています。
ユーザー管理・ソーシャルログイン・APIトークン発行をシンプルに追加したいだけなら、導入の摩擦は小さいです。
一方で、踏み止まったほうがいい状況もあります。
- 複雑なエンタープライズIdP連携が必須な場合。 SalesforceやWorkdayとの深い連携、あるいは特殊なSAML拡張が必要なケースでは、実績の豊富なAuth0やOktaのほうが安全です。
- 規制上のベンダー実績要件がある場合。 金融・医療など、認証基盤に特定の認定取得済みベンダーを求める規制がある環境では、Logtoの実績がまだ十分でない可能性があります。
- 運用体制がゼロのままセルフホストしようとしている場合。 PostgreSQLとRedisの運用を誰も見ない状態でセルフホストするのは、認証基盤が単一障害点になるリスクがあります。そういう状況ならCloud版から始めるべきです。
「踏み止まる状況」のうち最初の2つは、Logtoの問題というよりプロジェクト要件の問題です。
逆に言えば、その要件がなければ多くのケースでLogtoは十分に戦えます。
Next.jsとの接続イメージも見ておきましょう。
Pages RouterでLogtoClientを初期化してサインインハンドラを作る最小構成はこのようになります。
// libraries/logto.ts
import LogtoClient from '@logto/next';
export const logtoClient = new LogtoClient({
appId: process.env.LOGTO_APP_ID ?? '',
appSecret: process.env.LOGTO_APP_SECRET ?? '',
endpoint: process.env.LOGTO_ENDPOINT ?? '',
baseUrl: process.env.NEXT_PUBLIC_BASE_URL ?? '',
cookieSecret: process.env.LOGTO_COOKIE_SECRET ?? '',
cookieSecure: process.env.NODE_ENV === 'production',
});
// pages/api/logto/[action].ts
import { logtoClient } from '../../../libraries/logto';
export default logtoClient.handleAuthRoutes();
これだけでサインイン・サインアウト・コールバックのルートが生えます。
あとはサインインボタンから /api/logto/sign-in に飛ばすだけで、認証フロー全体が動きます。
Admin Consoleで設定したソーシャルログインやSSO設定も、このフローの中に自動的に組み込まれます。
認証基盤の選定は「どれが最強か」ではなく「自分のプロジェクトの制約と何がフィットするか」という問いです。
Logtoはその選択肢の中で、マルチテナント・データ主権・コスト構造の3点において、今まで見えにくかった隙間を埋めてくれる存在だと思っています。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進を手がけています。
認証基盤の選定や導入支援、SaaSアーキテクチャの設計相談など、実務に踏み込んだ形でお手伝いできます。
ご相談は お問い合わせページ からどうぞ。