OpenID Connect 実装：クライアント側とサーバー側の徹底比較

express-openid-connect と oidc-provider は、どちらも Node.js エコシステムで OpenID Connect プロトコルを扱いますが、全く異なる役割を果たします。前者はアプリにログイン機能を追加する「利用者側」のツールであり、後者は認証サーバーそのものを作る「提供者側」のツールです。この根本的な違いを理解しないと、アーキテクチャ設計で重大なミスを犯す可能性があります。

🎭 根本的な役割：ログイン機能 vs 認証サーバー

express-openid-connect は、既存の Identity Provider (IdP) に対してクライアントとして動作します。

• ユーザーを外部のログイン画面にリダイレクトします。
• 戻ってきたコードを交換してセッションを作成します。
• 開発者は認証サーバーの管理責任を負いません。

// express-openid-connect: クライアント側の実装
const { auth, requiresAuth } = require('express-openid-connect');

const config = {
  authRequired: false,
  auth0: {
    domain: 'YOUR_DOMAIN',
    clientId: 'YOUR_CLIENT_ID',
    clientSecret: 'YOUR_CLIENT_SECRET'
  },
  baseURL: 'http://localhost:3000',
  secret: 'LONG_RANDOM_STRING'
};

app.use(auth(config));

app.get('/profile', requiresAuth(), (req, res) => {
  res.send(req.oidc.user);
});

oidc-provider は、あなたが Identity Provider になるためのサーバー実装です。

• 他のアプリから認証リクエストを受け付けます。
• ユーザーのパスワードを検証し、トークンを発行します。
• 開発者はセキュリティとインフラの全責任を負います。

// oidc-provider: サーバー側の実装
const Provider = require('oidc-provider');

const provider = new Provider('http://localhost:3000', {
  clients: [
    {
      client_id: 'client-id',
      client_secret: 'client-secret',
      redirect_uris: ['http://localhost:3000/callback']
    }
  ],
  interactions: {
    url: '/interaction' // カスタムログイン画面へのパス
  }
});

app.use(provider.callback);

⚙️ 設定の複雑さ：宣言的 vs 構築的

express-openid-connect は設定オブジェクトを渡すだけで動作します。

• 必要な情報はドメインとクライアント ID だけです。
• 内部的なプロトコル処理はすべて隠蔽されています。
• 数分で導入できるため、スタートアップや内製ツールに適しています。

// express-openid-connect: シンプルな設定
const config = {
  auth0: {
    domain: 'tenant.auth0.com',
    clientId: 'client-id'
  },
  secret: 'session-secret' // セッション暗号化用
};

// これだけでログイン・ログアウト・プロフィール取得が有効化されます
app.use(auth(config));

oidc-provider はサーバーの挙動を細かく定義する必要があります。

• 対応するgrant タイプ、トークン形式、クライアント設定を明示します。
• ログイン画面や同意画面の UI を自前で実装して連携させます。
• 銀行や大規模プラットフォームなど、完全な制御が必要な場合に適しています。

// oidc-provider: 詳細な設定
const config = {
  features: {
    encryption: { enabled: true },
    jwtUserinfo: { enabled: true }
  },
  cookies: {
    names: {
      session: 'oidc.session',
      interaction: 'oidc.interaction'
    }
  },
  // ユーザー検証ロジックも自前で実装する必要があります
  async findAccount(ctx, id) {
    return { accountId: id }; 
  }
};

const provider = new Provider('http://localhost:3000', config);

🎨 UI とセッション：管理済み vs 自作

express-openid-connect はセッション管理を自動で行います。

• 暗号化された Cookie を自動的に設定します。
• トークンのリフレッシュもバックグラウンドで処理されます。
• ログイン画面は外部プロバイダーが表示するため、自作不要です。

// express-openid-connect: セッションは自動管理
app.get('/dashboard', requiresAuth(), (req, res) => {
  // req.oidc.isAuthenticated() でログイン状態を確認
  // req.oidc.user でユーザー情報を取得
  // セッション有効期限の更新も自動です
  res.render('dashboard', { user: req.oidc.user });
});

oidc-provider は UI フローを自分で構築します。

• /interaction エンドポイントなどでログインフォームを表示します。
• セッションの保存先や暗号化方法を自分で選べます。
• ブランディングや多要素認証を自由に組み込めます。

// oidc-provider: UI 連携は自前
app.get('/interaction', async (req, res) => {
  const { uid, prompt, details } = await provider.interactionDetails(req, res);
  // ここで独自のログインフォームをレンダリングします
  res.render('login', { uid, prompt });
});

// 認証完了後に provider に結果を返します
app.post('/interaction', async (req, res) => {
  const result = { login: { accountId: 'user123' } };
  await provider.interactionFinished(req, res, result);
});

🛠️ 保守とエコシステム：ベンダー依存 vs 自前維持

express-openid-connect は Auth0 によって维护されています。

• セキュリティアップデートはベンダー側で処理されます。
• 仕様変更にもベンダー側で対応してくれることが多いです。
• 特定のベンダーロックインが発生する可能性を考慮する必要があります。

// express-openid-connect: ベンダー依存の例
// Auth0 固有の機能拡張が使えますが、他プロバイダーでは動かない場合があります
const config = {
  auth0: {
    domain: 'specific-tenant.auth0.com' // 特定のテナントに依存
  }
};

oidc-provider はコミュニティと維持者によって支えられています。

• 仕様準拠性は高いですが、セキュリティパッチは自分で適用する必要があります。
• 内部実装を理解していないと、問題発生時の対応が困難です。
• ベンダーロックインはありませんが、技術負債として蓄積します。

// oidc-provider: 自前維持の例
// 設定変更やアップデートはすべて自分の責任で行います
const provider = new Provider('http://localhost:3000', {
  // セキュリティ設定も自分で管理します
  jwks: { keys: [/* 自分で管理する鍵 */] }
});

🤝 共通点：OpenID Connect 準拠

両者は役割が違いますが、同じプロトコル標準に従っています。

1. 🔐 標準プロトコルのサポート

• どちらも OpenID Connect Core 1.0 に準拠しています。
• 標準的なフロー（Authorization Code Flow）をサポートします。

// 両者とも標準的な OIDC フローを使用します
// express-openid-connect: 自動的に標準フローを実行
// oidc-provider: 標準フローを受け付けて処理する

2. 🔄 トークン処理

• ID トークン、アクセストークン、リフレッシュトークンを扱います。
• JWT 形式のトークンを生成・検証します。

// express-openid-connect: トークンを自動検証
const user = req.oidc.user; // ID トークンから抽出

// oidc-provider: トークンを発行
// 内部で JWT 署名を行い、クライアントに返却します

3. 🌐 Express 連携

• どちらも Express ミドルウェアとして動作します。
• 既存の Node.js アプリに組み込み可能です。

// 両者とも app.use() で導入可能
app.use(auth(config)); // express-openid-connect
app.use(provider.callback); // oidc-provider

📊 _summary: 主要な違い

💡 最終的な推奨

express-openid-connect は、認証そのものがビジネスのコアではない場合に最適です 🧰。ログイン機能を素早く実装し、セキュリティの負担を外部に任せたいプロジェクトに向いています。大多数の Web アプリケーションはこちらを選ぶべきです。

oidc-provider は、認証サービスそのものが製品である場合に最適です 🔧。ユーザーデータを自社で完全に管理し、他社に認証機能を提供したい場合にのみ選択してください。维护コストを十分に見積もった上で導入する必要があります。

重要な注意点: この 2 つは競合ではなく、組み合わせることも可能です。oidc-provider で自前の認証サーバーを作り、express-openid-connect でそのサーバーを使ってアプリにログインさせる構成も技術的に成立します。しかし、多くの場合、既存のマネージドサービスを使う方がコスト効率が良くなります。