Auth0とOktaのどちらを選ぶか、という形で相談を受けることがあります。ただしこの問いの立て方は、2021年にOktaがAuth0を買収して以降、実態と少しずれています。両者は競合する別会社の製品ではなく、同じ会社が持つ二つの製品ラインだからです。選定で先に決めるべきは製品名ではなく、認証する相手が顧客なのか従業員なのかという点になります。ここを取り違えると、契約後に課金単位が合わずに見積りが崩れます。
まとめ｜Auth0とOktaの違いは認証する相手が顧客か従業員かで決まる
結論を先に置きます。Auth0は現在、Oktaの顧客ID向け製品ライン（Customer Identity Cloud、以下CIC）の中核として提供されています。一方、いわゆる「Okta」として語られる従業員向けのSSOやライフサイクル管理は、Workforce Identity Cloud（以下WIC）という別ラインです。したがって比較すべきは製品の優劣ではなく、対象ユーザーの種別です。
自社サービスの会員やエンドユーザーにログインさせるならCIC側、つまりAuth0を前提に設計します。社内の従業員にSaaS群へのSSOを提供し、入退社に合わせてアカウントを配布・剥奪したいならWIC側です。この二つは課金単位も管理画面も別で、片方でもう片方の要件を無理に賄おうとすると費用と実装の両面で歪みます。
費用面の差も課金単位に由来します。CICは月間アクティブユーザー（MAU）で数え、WICは従業員数で数えます。会員100万人のサービスを従業員数課金の製品に載せることはできませんし、従業員300人の社内SSOをMAU課金で見積もっても実態に合いません。見積りの前に、認証する母集団が何人で、そのうち毎月ログインするのは何人かを確定させてください。
採用してよい条件は明確です。顧客向けサービスで、ソーシャルログインや独自のサインアップ画面を作り込みたく、認証まわりの自前実装を避けたい場合、CIC（Auth0）は有力な選択肢になります。逆に見送る場面もあります。認証対象が社内の数十人で、既にMicrosoft EntraやGoogle Workspaceを契約しているなら、そこに含まれるSSO機能で足りることが多く、追加のIDaaSは費用に見合いません。ソースコードを手元に置いて監査したい、あるいはクラウドに認証情報を置けない制約があるなら、OSSのKeycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断で扱っている自前運用の道もあります。
Auth0がOktaに買収され顧客ID基盤という位置づけに変わった経緯
製品ラインの分かれ方を理解するには、買収からの流れを押さえておくと早いです。ここを曖昧にしたまま比較記事を読むと、実際には併存している二つの製品を、どちらか一方を選ぶ二択の話として読んでしまいます。
2021年の買収から現在までにOktaが示した製品統合の方針
OktaによるAuth0の買収完了は2021年5月です。Oktaの公式ページでは、買収後もAuth0は独立したビジネスユニットとして運営され、両プラットフォームともサポートと投資を継続し、時間をかけて統合していく方針が示されています。実際の運用でもこの方針どおりで、Auth0のテナントは買収前と同じように作成でき、管理画面もAuth0のものが使われ続けています。
ここで押さえておきたいのは、統合という言葉が「片方の廃止」を意味していない点です。設計判断としては、Auth0が近い将来に消えることを前提にした回避策を組む必要はありません。ただし製品名の表記は公式資料の中でも揺れがあるため、契約書やSLAを確認するときは、どちらのラインの話をしているのかを必ず確認してください。
顧客向けCICと従業員向けWICという二つの製品ラインの役割分担
現在のOktaの製品体系は、大きく二つに分かれます。Customer Identity Cloudは顧客・エンドユーザーの認証を担い、その実体がAuth0です。Workforce Identity Cloudは従業員の認証とアクセス管理を担い、社内SaaSへのSSO、プロビジョニング、デバイス条件によるアクセス制御などを含みます。
この分け方は業界ではCIAM（顧客IAM）とWorkforce IAMという呼称で整理されることが多く、求められる要件が根本的に違います。顧客向けは、サインアップ画面の見た目を自社ブランドに合わせられるか、ソーシャルログインを足せるか、ピーク時の同時ログインに耐えるかが問われます。従業員向けは、人事システムと連携して入社時にアカウントを配り、退職時に確実に止められるかが問われる領域です。同じ「認証」でも設計の関心事が重ならないため、製品も分かれています。
Auth0という名称が製品名として残っている範囲と公式の表記
公式の表記では「Okta Customer Identity Cloud（powered by Auth0）」という形が使われます。CICのプラン改定に関する公式発表でもこの表記です。一方で開発者向けのドキュメントやSDKの名称、npmパッケージ名は今もauth0のままで、実装時に触る対象はすべてAuth0の名前で流通しています。
提案書を書くときは、この二層構造を意識すると誤解が減ります。契約・調達の文脈では「Okta CIC」、実装・設計の文脈では「Auth0」と書き分ける形が実務では扱いやすい表現です。
顧客の認証か従業員の認証かで使う製品が分かれる選定時の判断軸
前提が整理できたところで、実際の案件でどちらを選ぶかの判断に移ります。判断は機能表の突き合わせではなく、認証する母集団の性質から入ると迷いが減ります。
認証する相手が顧客ならば開発の自由度でAuth0側を選ぶ理由
顧客向けサービスでは、ログイン画面が製品体験の一部になります。ここを既製のUIで妥協できない案件では、画面を自前で作りながら認証処理だけを外部に預けられる構成が必要です。Auth0はこの用途を想定しており、ホスト型のログイン画面をテーマで調整する方法と、自前画面からAPIを叩く方法の両方を選べます。
もう一つの理由は、認証フローに独自の処理を挟める点です。ログイン直後に自社DBの会員ステータスを引いてトークンに載せる、初回ログイン時だけ規約同意画面を出すといった要件は、顧客向けでは頻出します。Auth0にはActionsという仕組みがあり、ログイン処理の途中にJavaScriptを差し込めます。従業員向け製品でこの種の作り込みを求めると、製品の想定から外れた使い方になりがちです。
社内システムのアクセス管理が主目的ならWIC側が前提になる場面
認証対象が従業員の場合、求められるのは画面の作り込みではなく、アカウントのライフサイクル管理です。入社時に人事システムの登録をきっかけとしてSaaS群のアカウントを一括で作り、異動で権限を付け替え、退職時に即座に無効化する。この一連を人手で回すと必ず剥奪漏れが出ますし、監査でも指摘されます。
WICはこの用途の製品で、多数のSaaSに対する既製のコネクタと、プロビジョニングの仕組みを持っています。ここをAuth0で代替しようとすると、SaaSごとの連携を自前で書くことになり、本来なら設定で済む部分が開発案件に変わる構図です。社内向けの認証連携で使うSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説の内容は、この文脈で必要になります。
両方が必要になる案件で二重契約を避けるための切り分けの考え方
自社サービスを提供しつつ、社内のSaaS管理も整えたいという案件では、両方が必要になります。このとき、片方に寄せて費用を抑えようとする発想が出ますが、実務では逆効果になりやすいです。
切り分けの基準はシンプルで、認証情報の管理主体が誰かで分けます。ユーザー自身が登録・退会するならCIC、会社が付与・剥奪するならWICです。この線で分けておくと、後から会員数が増えても従業員が増えても、片方の増減がもう片方の費用に影響しません。逆に混在させると、退職者アカウントがMAUに数えられて費用が膨らむ、といった事故が起きます。
料金は課金単位が異なりMAUと従業員数で見積り額が大きく変わる
費用の見積りは、単価表を見る前に課金単位を確認するところから始めます。ここを外すと桁が変わります。以下は2026年9月時点の公開情報にもとづく整理で、実際の適用条件は営業経由の見積りで確定させてください。
Auth0はMAU課金で無料枠の範囲と超過後の単価を確認する
Auth0の課金は月間アクティブユーザー数が基準です。Auth0公式の料金ページでは無料枠とプラン別の上限が示されており、無料枠の範囲は改定されることがあります。前述の公式発表でも、無料プランの拡充と有料プランの機能強化がアナウンスされています。
見積りで注意すべきは、MAUの定義です。登録会員数ではなく、その月に実際に認証が発生したユーザーの数で数えます。会員10万人でも月間ログインが8千人なら、課金対象は8千人側です。逆にキャンペーンで一時的にログインが集中する月があると、その月だけ上位プランの帯に入ります。年間の費用を見るときは、平均ではなく月ごとの変動幅で見てください。
| 観点 | CIC（Auth0） | WIC（Okta） |
|---|---|---|
| 課金単位 | 月間アクティブ数 | 従業員数 |
| 対象 | 顧客・会員 | 社内の従業員 |
| 管理の主体 | ユーザー本人 | 会社の管理者 |
| 画面の自由度 | 作り込みやすい | 既製UIが中心 |
| 主な連携先 | 自社アプリとAPI | 社内のSaaS群 |
Oktaは従業員数課金で機能ごとに単価が積み上がっていく構造
WIC側は従業員1人あたりの月額を、使う機能ごとに積み上げる形です。Oktaの料金ページを見ると、SSO、多要素認証、ライフサイクル管理などが個別の単位で並んでいます。「1人あたり何ドル」という単一の数字ではないため、必要な機能を先に確定させないと見積りが出ません。
また契約の最低額が設定されている場合があり、従業員数が少ないと1人あたりの実効単価が跳ね上がります。数十人規模で検討するときは、この最低額の条件を先に確認してください。実装側で用意する多要素認証（MFA）とは？3つの認証要素と実装方式・耐フィッシングMFAを実装視点で解説の要件も、どのプランに含まれるかで費用が変わります。
見積り時に見落としやすいM2Mトークンと組織機能の追加費用の扱い
MAU課金の外側で費用が発生する項目が二つあります。一つはM2M（マシン間通信）トークンです。バッチ処理やサーバ間連携でアクセストークンを取得する場合、人間のログインではないためMAUには数えられませんが、別枠で課金対象になります。日次バッチが多いシステムでは、この発行数が想定を超えることがあります。
もう一つはマルチテナント向けの組織機能です。B2Bサービスで顧客企業ごとにログイン設定を分けたい、企業ごとに別のIdPと連携したいという要件は、上位プランや追加オプションの領域になります。B2B案件では、この要件があるかないかで費用の桁が変わるため、要件定義の早い段階で確認してください。
Auth0のAPIとSDKで認証フローを実装する最小構成のコード例
ここからは選定の話を終えて実装の説明です。ここでは検証環境を作る前提で、SPAとAPIを分けた最小構成を示します。手元での確認手順はAuth0公式ドキュメントのGet Startedに沿っています。
SPAとAPIを分けてAuth0テナントに登録する初期設定の手順
Auth0では、フロントエンドを「Application」、バックエンドを「API」として別々に登録します。この分離を最初にやっておかないと、後からアクセストークンの受け渡しで詰まる原因です。登録後に得られる値をアプリ側の環境変数に置きます。
AUTH0_DOMAIN=your-tenant.jp.auth0.com
AUTH0_CLIENT_ID=your_spa_client_id
AUTH0_AUDIENCE=https://api.example.com
AUTH0_SCOPE=openid profile email read:ordersAUTH0_AUDIENCEにはAPI登録時に決めた識別子を入れます。これは実在するURLである必要はなく、識別子として使う文字列です。ここを空にするとIDトークンだけが発行され、API側で検証できるアクセストークンが手に入りません。初回に詰まる箇所の筆頭です。
アクセストークンを検証するAPI側の実装で必要になる設定値の例
API側は、受け取ったアクセストークンの署名と発行者を検証します。Node.jsのExpressであれば、公式が提供するミドルウェアで数行です。自前でJWTを検証する実装を書くと鍵のローテーションに対応できず、事故のもとになります。
const { auth } = require('express-oauth2-jwt-bearer');
app.use(auth({
audience: 'https://api.example.com',
issuerBaseURL: 'https://your-tenant.jp.auth0.com/'
}));
app.get('/orders', function (req, res) {
res.json({ sub: req.auth.payload.sub });
});issuerBaseURLの末尾のスラッシュは省略できません。ここが欠けると署名検証の前段で失敗し、原因が分かりにくいエラーになります。検証時はまずこの2値を疑ってください。
ロールと権限をカスタムクレームで渡すときのルールの記述の仕方
アプリ側で権限判定をしたい場合、ロールをトークンに載せます。Auth0ではActionsを使い、ログイン後の処理でクレームを追加する仕組みです。名前空間付きのキーにする決まりがあり、これを守らないとクレームが無視されます。
exports.onExecutePostLogin = async function (event, api) {
var ns = 'https://api.example.com/claims';
var roles = event.authorization ? event.authorization.roles : [];
api.idToken.setCustomClaim(ns + '/roles', roles);
api.accessToken.setCustomClaim(ns + '/roles', roles);
};IDトークンとアクセストークンの両方に載せている点に注目してください。フロントで表示を切り替えるにはIDトークン、API側で認可判定をするにはアクセストークンが要ります。片方だけに載せると、画面では権限があるように見えるのにAPIが拒否する、という食い違いが起きます。
既存の認証基盤から移行するときに詰まる箇所と事前確認すべき項目
新規構築より難しいのが、稼働中のサービスからの移行です。会員を再登録させずに移す前提で考えると、確認すべき点が絞られます。
既存のパスワードハッシュを移行できる条件と移行できない場合の対応
既存DBのパスワードハッシュは、アルゴリズムが対応形式であれば取り込めます。bcryptのように広く使われている形式なら、ハッシュ値のままインポートでき、会員はこれまでのパスワードでログインを続けられます。
問題は、独自のソルト付与や社内独自のハッシュを使っている場合です。この場合は一括インポートができず、初回ログイン時に旧システムへ問い合わせて検証し、成功したらAuth0側に登録し直す段階的な移行になります。移行期間中は旧システムを止められないため、切り替え計画の期間が延びます。要件確認の段階で、ハッシュのアルゴリズムとソルトの持ち方を必ず確認してください。
認証方式の変更でクライアント側に発生する改修の範囲と工数の目安
セッションCookieによる認証からトークンベースに変わる場合、フロントエンドの改修が広範囲に及びます。APIリクエストへのAuthorizationヘッダ付与、トークンの保管場所の決定、期限切れ時の再取得処理、ログアウト時の破棄。既存コードで認証状態をグローバル変数に持っていると、この置き換えが各画面に波及します。
スマートフォンアプリを併せて提供している場合は、アプリ側のリリース審査の期間も見込む必要があります。Webだけなら数週間で切り替えられても、アプリの旧バージョンが残る前提だと、両方式を並行して受け付ける期間が必要です。移行の設計は、この並行期間をどこまで許容するかで工数が決まります。認証基盤を含む会員まわりの構築は認証基盤・ID管理システム開発で承っており、既存システムからの移行計画づくりから対応しています。
よくある質問
Auth0とOktaはどちらか一方だけを選ぶ必要がありますか？
その必要はありません。顧客向けと従業員向けで対象が異なるため、両方を並行して使う構成が一般的です。自社サービスの会員認証はCIC（Auth0）、社内SaaSのSSOはWICという形で分けます。管理画面と契約は別になりますが、用途が重ならないため運用上の混乱は起きにくいです。
OktaがAuth0を買収したあと、Auth0は終了しますか？
公式には、買収後もAuth0への投資とサポートを継続し、時間をかけて統合していく方針が示されています。2026年9月時点でテナントの新規作成もSDKの提供も続いており、終了を前提にした設計変更は不要です。ただし契約更改時には、製品名の表記がOkta CICになっている場合があるため、対象を確認してください。
Auth0の無料プランは商用サービスで使えますか？
無料プランでも商用利用は可能ですが、MAUの上限とカスタムドメインの可否が制約になります。ログイン画面を自社ドメインで出したい場合、無料プランでは対応できないことがあります。会員数が少ないうちは無料枠で始め、カスタムドメインが必要になった時点で移行するという進め方が現実的です。
既存のIDaaSからAuth0へ移行する期間はどのくらいですか？
パスワードハッシュを一括インポートできる場合、会員数10万人規模でも切り替え自体は短期間で済みます。判断を分けるのはクライアント側の改修量です。Webのみで認証処理が1箇所にまとまっていれば1〜2か月、モバイルアプリを含み認証状態が各画面に散らばっている場合は3〜6か月を見込む案件が多いです。
社内はOkta、顧客向けはAuth0という構成で認証は連携できますか？
連携できます。管理者が顧客向けサービスの管理画面にログインする場面では、WIC側をIdPとしてAuth0にフェデレーションする構成が可能です。この場合、従業員は普段のSSOでそのまま管理画面に入れます。顧客のログインとは経路が分かれるため、権限の混在も避けられます。
