Auth0 を学ぶ ── IDaaS による認証・認可の基本を理解する

この記事で分かること

• Auth0 とは何か、IDaaS が解決する課題
• Tenant・Application・Connection・API の基本コンセプト
• OAuth 2.0 / OpenID Connect に基づく認証フローの仕組み
• Universal Login・MFA・Actions・Organizations などの主要機能
• Auth0 の料金体系と選定のポイント

はじめに

Web アプリケーションやモバイルアプリを開発するとき、ほぼ必ず必要になるのが「認証」と「認可」の仕組みです。ユーザーが誰であるかを確認し（認証）、そのユーザーに何を許可するかを制御する（認可）必要があります。

一見シンプルに思えるこの仕組みですが、自前で実装しようとすると考慮すべき点が多くあります。

• パスワードの安全なハッシュ化とストレージ
• ブルートフォース攻撃や Credential Stuffing への対策
• MFA（多要素認証）の導入
• OAuth 2.0 / OpenID Connect の仕様準拠
• セッション管理とトークンのライフサイクル
• ソーシャルログイン（Google、GitHub など）の統合
• セキュリティパッチの継続的な適用

これらをすべて正しく実装・運用し続けるのは、認証が本業でないチームにとって大きな負担です。ここで Auth0 のような IDaaS（Identity as a Service）が選択肢に入ってきます。

Auth0 とは

Auth0 は、認証・認可をサービスとして提供する IDaaS プラットフォームです。2013 年に設立され、2021 年に Okta に買収されました。現在は Okta のデベロッパー向けプロダクトとして位置付けられています。

IDaaS とは

IDaaS は、ユーザー認証・認可・ユーザー管理といったアイデンティティ関連の機能をクラウドサービスとして提供する形態を指します。自前で認証基盤を構築・運用する代わりに、API やダッシュボードを通じてこれらの機能を利用できます。

自前実装と比較すると、以下のような違いがあります。

Auth0 と Okta の関係

Okta は企業の従業員向けアイデンティティ管理（Workforce Identity）を強みとするプラットフォームです。一方、Auth0 はアプリケーションの顧客向けアイデンティティ管理（Customer Identity）に特化しています。

Okta による買収後も Auth0 は独立したプロダクトとして運営されており、ダッシュボード・SDK・ドキュメントはすべて Auth0 ブランドで提供されています。

Auth0 の主要コンセプト

Auth0 を理解するうえで押さえておきたい 4 つの基本概念があります。

Tenant

Tenant は Auth0 における最上位の分離単位です。すべての設定・ユーザーデータ・ログは Tenant に紐づきます。

一般的には環境ごと（Development / Staging / Production）に Tenant を分けて運用します。Tenant 間のデータは完全に分離されるため、開発環境の設定変更が本番に影響することはありません。

my-app-dev.auth0.com    ← Development Tenant
my-app-staging.auth0.com ← Staging Tenant
my-app.auth0.com         ← Production Tenant

Application

Application は、Auth0 に認証を委譲するクライアントアプリケーションの登録単位です。Application を作成すると Client ID が発行されます（Regular Web Application や M2M など confidential client の場合は Client Secret も発行）。

用途に応じて以下のタイプが用意されています。

このタイプの選択が、後述する認証フローの選択にも関わってきます。

Connection

Connection は、ユーザーの認証方法を定義する設定です。「どのようにユーザーを認証するか」を決める部分にあたります。

大きく 4 種類に分類されます。

• Database Connection: Auth0 がユーザー名・パスワードを管理する。最もシンプルな構成。パスキー（Passkeys）にも対応しており、パスワードレスなログインを実現できる
• Social Connection: Google、GitHub、Apple などの外部 IdP を利用したソーシャルログイン
• Enterprise Connection: SAML、OIDC、Active Directory などの企業向け IdP との連携
• Passwordless Connection: メールのマジックリンクや SMS の OTP によるパスワードレス認証

1 つの Application に複数の Connection を紐づけることで、ユーザーはログイン画面で認証方法を選択できます。

API（Resource Server）

API は、Auth0 が保護対象として認識するバックエンド API の登録単位です。OAuth 2.0 における Resource Server に対応します。

API を登録すると Audience（識別子）が設定されます。クライアントはトークンリクエスト時にこの Audience を指定し、発行されたアクセストークンで API にアクセスします。

Audience: https://api.my-app.com

コンセプト間の関係

これら 4 つのコンセプトの関係を整理すると、以下のようなツリー構造になります。

Tenant
├── Application（SPA, Web App, Native, M2M）
│   └── 許可された Connection を指定
├── Connection（Database, Social, Enterprise, Passwordless）
│   └── ユーザーの認証方法を定義
├── API（Resource Server）
│   └── アクセストークンの Audience を定義
└── User
    └── Connection を通じて認証されたユーザー

この関係を把握しておくと、Auth0 のダッシュボードで何を設定しているのかが理解しやすくなります。

認証フロー

Auth0 は OAuth 2.0 と OpenID Connect（OIDC）に準拠した認証フローを提供しています。アプリケーションの種類に応じて適切なフローを選択する必要があります。

Authorization Code Flow + PKCE

SPA やモバイルアプリなどの public client で推奨されるフローです。PKCE（Proof Key for Code Exchange）を併用することで、Authorization Code の横取り攻撃を防ぎます。

なお、2025 年 1 月に公開された RFC 9700（OAuth 2.0 Security Best Current Practice）では、PKCE はすべてのクライアントで必須とされています。策定中の OAuth 2.1 でも同様に PKCE が必須化される方向です。

1. ユーザーがログインボタンをクリック
2. アプリが code_verifier と code_challenge を生成
3. Auth0 の /authorize エンドポイントにリダイレクト
   （code_challenge を送信）
4. Auth0 がログイン画面を表示（Universal Login）
5. ユーザーが認証情報を入力
6. Auth0 が Authorization Code を発行してアプリにリダイレクト
7. アプリが Authorization Code + code_verifier を /oauth/token に送信
8. Auth0 が code_verifier を検証し、トークンを発行
   ├── ID Token（ユーザー情報）
   ├── Access Token（API アクセス用）
   └── Refresh Token（トークン更新用、オプション）

ステップが多く見えますが、実際には SDK がほとんどの処理を隠蔽してくれるので、開発者が意識するのはログインボタンの設置とコールバックの処理くらいです。

Authorization Code Flow（サーバーサイド）

Regular Web Application のように Client Secret を安全に保持できる環境（confidential client）では、Client Secret を使った Authorization Code Flow を使います。サーバーサイドで Client Secret を使ってトークンを取得するため、Secret がブラウザに露出しません。

Auth0 では confidential client に対して PKCE なしのフローもサポートしていますが、前述の RFC 9700 を踏まえると、confidential client でも PKCE を併用するのがベターです。Auth0 は confidential client からの PKCE フローにも対応しています。

Client Credentials Flow

Machine to Machine（M2M）通信で使用するフローです。ユーザーの介在なしに、Client ID と Client Secret でアクセストークンを取得します。

curl --request POST \
  --url https://my-app.auth0.com/oauth/token \
  --header 'content-type: application/json' \
  --data '{
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "audience": "https://api.my-app.com",
    "grant_type": "client_credentials"
  }'

フロー選定の指針

アプリケーション種別ごとの推奨フローは以下のとおりです。

Auth0 の主要機能

Universal Login

Universal Login は、Auth0 がホストするログインページです。アプリケーション側でログインフォームを実装する代わりに、Auth0 のページにリダイレクトしてユーザー認証を行います。

Universal Login を使うメリットは大きいです。

• セキュリティ: 認証情報がアプリケーションのドメインを経由しない
• SSO: 複数アプリケーション間でシングルサインオンが自動的に有効になる
• カスタマイズ: ダッシュボードからブランディング（ロゴ、カラー）を設定可能
• メンテナンス: セキュリティアップデートが Auth0 側で自動適用される

Auth0 の SDK（@auth0/auth0-react, @auth0/nextjs-auth0 など）を使えば、数行のコードで Universal Login を統合できます。

MFA（多要素認証）

Auth0 では MFA をダッシュボードの設定で有効化できます。Free プランでは Email / SMS による Passwordless 認証が利用可能ですが、以下のような高度な MFA 機能は Essentials プラン以上が必要です。

• OTP（ワンタイムパスワード）: Google Authenticator などの TOTP アプリ
• SMS: 電話番号への確認コード送信
• Email: メールアドレスへの確認コード送信
• Push 通知: Auth0 Guardian アプリによるプッシュ承認
• WebAuthn: FIDO2 対応のセキュリティキーや生体認証

Adaptive MFA（Enterprise プラン + アドオンが必要）を使えば、リスクベースで MFA を要求することも可能です。通常のログインでは MFA をスキップし、不審なアクセス（新しい IP、新しいデバイスなど）のときだけ追加認証を求めるといった運用ができます。

Actions

Actions は、認証フローの特定のタイミングでカスタムロジックを実行する仕組みです。Node.js で記述し、Auth0 のダッシュボードまたは Deploy CLI で管理します。

主なトリガーポイントは以下のとおりです。

以下は Post Login Action でカスタムクレームを追加する例です。

exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://my-app.com';

  if (event.authorization) {
    api.idToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles);
    api.accessToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles);
  }
};

なお、Auth0 には以前 Rules や Hooks という仕組みがありましたが、2023 年 5 月に非推奨となり、2024 年 11 月に読み取り専用へ移行しました。2026 年 11 月 18 日に完全に廃止（End of Life）される予定です。新規で導入する場合は Actions を使います。

Organizations

Organizations は、B2B SaaS アプリケーションでマルチテナンシーを実現するための機能です。

• 組織ごとにメンバー管理・Connection 設定・ブランディングを分離できる
• 組織ごとに異なる IdP（例: A 社は Okta SSO、B 社は Google Workspace）を設定できる
• 招待フローやメンバーのロール管理がビルトインで提供される

Tenant
├── Organization: Acme Corp
│   ├── Connection: Okta (SAML)
│   └── Members: user1, user2
├── Organization: Globex Inc
│   ├── Connection: Google Workspace
│   └── Members: user3, user4
└── Organization: Initech
    ├── Connection: Database
    └── Members: user5

B2B SaaS で「顧客企業ごとに SSO を設定したい」というのはよくある要件ですが、Organizations を使えばこれを Auth0 側で管理できます。Organizations は Free プランでも 5 つまで作成可能です。

RBAC（ロールベースアクセス制御）

Auth0 にはビルトインの RBAC 機能があります（Essentials プラン以上が必要）。ロールと権限（Permission）を定義し、ユーザーに割り当てることで、API レベルのアクセス制御を実現します。

Role: admin
├── Permission: read:users
├── Permission: write:users
└── Permission: delete:users

Role: viewer
└── Permission: read:users

RBAC を有効化すると、アクセストークンに permissions クレームが自動で含まれます。API 側ではこのクレームを検証するだけで、きめ細かいアクセス制御が可能です。

料金体系

Auth0 の料金は MAU（Monthly Active Users）ベースで課金されます。また、有料プランは B2C 向けと B2B 向けで分かれています。

Free プランでも 25,000 MAU まで利用でき、Social Connection も無制限のため、個人プロジェクトやスタートアップの初期段階では十分な場合が多いです。ただし、MFA や RBAC は Essentials 以上のプランが必要になります。

料金の詳細は Auth0 Pricing を確認してください。

まとめ

• Auth0 は認証・認可をサービスとして提供する IDaaS プラットフォーム
• Tenant・Application・Connection・API の 4 つの基本概念を押さえると全体像が掴める
• アプリケーションの種類に応じて適切な認証フロー（Authorization Code + PKCE, Client Credentials など）を選択する
• Universal Login を使うことで、セキュリティと開発効率の両方を確保できる
• Actions でカスタムロジックを追加し、Organizations で B2B マルチテナンシーに対応できる

参考

• Auth0 Documentation
• Auth0 Architecture Scenarios
• OAuth 2.0 Authorization Framework (RFC 6749)
• Proof Key for Code Exchange (RFC 7636)
• Best Current Practice for OAuth 2.0 Security (RFC 9700)
• OpenID Connect Core 1.0
• Auth0 Pricing

ぴょい

しがないソフトウェアエンジニアです。 学んだことをメモがわりに書いています。たまに技術以外の話も。 このブログの内容は個人の見解であり、所属組織とは関係ありません。記載内容には誤りがある可能性がありますので、公式ドキュメント等もあわせてご確認ください。