문서가격블로그
문의하기
로그인무료로 가입하기
Back to Tech Articles

Session、JWT、SSO、OAuth 2.0：メリット、デメリットおよびユースケース

2월 04, 2025
# Backend# JavaScript# Auth

James Reed

Infrastructure Engineer · Leapcell

이 게시물은 English, 한국어 및 Deutsch에서도 볼 수 있습니다.
Cover of "Session、JWT、SSO、OAuth 2.0：メリット、デメリットおよびユースケース"

フロントエンドプロジェクトの開発において、ユーザー認証には主にSession、JWT、SSO、OAuth 2.0の4つの方法があります。

では、これら4つの方法にはどのような利点と欠点があるのでしょうか？今日は、それらを比較してみましょう！

古典的なセッションベース認証

セッションベース認証とは？

セッションベース認証は、フロントエンドおよびバックエンドシステムで一般的に使用されるユーザー認証方法です。

これは主に、サーバーがユーザーセッションを作成および管理することに依存しています。

セッションの仕組み

セッション認証プロセスは、次の6つのステップで構成されています。

  1. ユーザーログイン: ユーザーは、ログインページに自分の資格情報（例：ユーザー名とパスワード）を入力します。これらの資格情報は、検証のためにフロントエンドからバックエンドサーバーに送信されます。
  2. セッションの作成: 資格情報の検証後、バックエンドサーバーはセッションを作成します。通常、これには一意のセッションIDが含まれており、サーバーに保存されます。
  3. セッションIDの返却: サーバーは、通常はCookieを介して、セッションIDをフロントエンドに返送します。このCookieはユーザーのブラウザに保存され、以降のリクエストで自動的に送信されます。
  4. セッションIDの保存: ブラウザはCookieを保存し、サーバーに送信されるすべてのリクエストに自動的に含めます。これにより、サーバーはユーザーのセッションを認識し、認証することができます。
  5. セッションの検証: サーバーはセッションIDを検索し、関連するセッション情報を検証してユーザーの身元を特定します。また、セッションデータを使用して、権限チェックやアクセス制御を行うこともできます。
  6. セッションの有効期限と管理: サーバーはセッションの有効期限を設定し、期限切れのセッションを定期的にクリアできます。ユーザーがログアウトするか、セッションがタイムアウトすると、サーバーはセッションを削除または無効にします。

上記のプロセスからわかるように、セッションベース認証では、フロントエンドが積極的に関与する必要はありません。主要な操作は、ブラウザとサーバーの間で処理されます。

長所と短所

長所

  • シンプルで使いやすい: 開発者にとって、セッションとユーザー認証の管理は比較的簡単です。
  • 優れた互換性: ほとんどのブラウザはCookieをサポートしており、自動的な送受信が可能です。

短所

  • 低いスケーラビリティ: 分散システムでは、複数のサーバーがセッションストレージを共有する必要がある場合があり、複雑さが増します。
  • HTTPSが必要: Cookieが盗まれた場合、セッションハイジャックにつながる可能性があります。したがって、HTTPSを使用してデータ伝送を保護する必要があります。追加のセキュリティ対策（例：HttpOnlyおよびSecure属性を使用したCookieの設定）も必要です。

コード例

Expressを使用したセッション認証の実装例を次に示します。

const express = require('express');
const session = require('express-session');
const app = express();

// express-sessionミドルウェアの設定と使用
app.use(
  session({
    secret: 'your-secret-key', // セッションID Cookieの署名に使用されるキーで、セッションのセキュリティを確保
    resave: false, // リクエストごとにセッションを保存するかどうか。変更がない場合でも保存
    saveUninitialized: true, // 初期化されていないセッションを保存するかどうか
    cookie: {
      secure: true, // CookieをHTTPS経由でのみ送信するかどうか（HTTPSサポートが必要）
      maxAge: 24 * 60 * 60 * 1000, // Cookieの有効期限（24時間に設定）
    },
  })
);

// ログインルートハンドラー
app.post('/login', (req, res) => {
  // ユーザー認証（ユーザーが検証済みと仮定）
  const user = { id: 123 }; // ユーザーIDの例
  req.session.userId = user.id; // ユーザーIDをセッションに保存
  res.send('ログイン成功');
});

app.get('/dashboard', (req, res) => {
  if (req.session.userId) {
    // セッションにユーザーIDが含まれている場合、ユーザーはログインしています
    res.send('ダッシュボードのコンテンツ...');
  } else {
    // セッションにユーザーIDが見つからない場合、ユーザーはログインしていません
    res.send('ログインしてください...');
  }
});

app.listen(3000, () => {
  console.log('サーバーはポート3000でリッスンしています...');
});

JWT（JSON Web Token）認証

JWT認証とは？

JWT認証は現在、最も一般的に使用されている認証方法の一つです。

サーバーは、ユーザーIDを表すトークンを返します。リクエストでは、このトークンがユーザー検証のためにリクエストヘッダーに追加されます。

HTTPリクエストはステートレスであるため、この方法はステートレス認証とも呼ばれます。

JWTの仕組み

  1. ユーザーログイン: ユーザーはログインページに自分の資格情報（例：ユーザー名とパスワード）を入力し、これらの資格情報は検証のためにバックエンドサーバーに送信されます。
  2. JWTの生成: ユーザーの資格情報を検証した後、バックエンドサーバーはJWTを生成します。このトークンには通常、基本的なユーザー情報（例：ユーザーID）とメタデータ（例：有効期限）が含まれます。
  3. JWTの返却: サーバーは、通常はJSONレスポンスで、生成されたJWTをフロントエンドに返送します。
  4. JWTの保存: フロントエンドは、通常はlocalStorageにJWTをクライアント側に保存します。まれに、Cookieに保存されることもありますが、これは**クロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）**などのセキュリティリスクを伴います。
  5. リクエストにJWTを使用: API呼び出しを行う際、フロントエンドはAuthorizationヘッダー（形式：Bearer <token>）にJWTトークンを添付してサーバーに送信します。
  6. JWTの検証: リクエストを受信すると、サーバーはJWTを抽出し、その有効性（例：署名と有効期限の確認）を検証します。有効な場合、サーバーはリクエストを処理し、対応するリソースまたはデータを返します。
  7. リクエストへの応答: サーバーはリクエストを処理し、応答を返します。フロントエンドは必要に応じてこれを使用できます。

長所と短所

長所

  • ステートレス: JWTは自己完結型であるため、サーバーはセッション情報を保存する必要がなく、スケーラビリティと負荷分散が簡素化されます。
  • クロスドメインサポート: JWTはクロスオリジンリクエストで使用できます（例：APIとフロントエンドが分離されている場合）。

短所

  • セキュリティ上の懸念: JWTのセキュリティは、キーの保護とトークンの有効期限管理に依存します。JWTが盗まれた場合、セキュリティリスクが生じる可能性があります。

コード例

Expressを使用したJWT認証の実装例を次に示します。

const express = require('express');
const jwt = require('jsonwebtoken');
const bodyParser = require('body-parser');
const app = express();

app.use(bodyParser.json());

const secretKey = 'your-secret-key'; // JWTの署名と検証に使用する秘密鍵

// JWTを生成するログインルート
app.post('/login', (req, res) => {
  const { username, password } = req.body;
  // ユーザー認証（ユーザーが有効と仮定）
  const user = { id: 1, username: 'user' }; // ユーザーデータの例
  const token = jwt.sign(user, secretKey, { expiresIn: '24h' }); // JWTを生成
  res.json({ token }); // JWTを返却
});

// 保護されたルート
app.get('/dashboard', (req, res) => {
  const token = req.headers['authorization']?.split(' ')[1];
  if (!token) {
    return res.status(401).send('トークンが提供されていません');
  }
  jwt.verify(token, secretKey, (err, decoded) => {
    if (err) {
      return res.status(401).send('無効なトークン');
    }
    res.send('ダッシュボードのコンテンツ');
  });
});

app.listen(3000, () => {
  console.log('サーバーはポート3000でリッスンしています...');
});

SSO（シングルサインオン）認証

SSO認証とは？

SSO認証は、**「スイートベース」**のアプリケーションで一般的に使用されています。中央ログインシステムを通じて、ユーザーは一度ログインするだけで、再認証なしに複数のアプリケーションにアクセスできます。

SSOの仕組み

  1. ユーザーがアプリケーションにアクセス: ユーザーは認証を必要とするアプリケーション（**サービスプロバイダー（SP）**と呼ばれる）にアクセスしようとします。
  2. IDプロバイダー（IdP）へのリダイレクト: ユーザーがログインしていないため、アプリケーションはユーザーをSSO IDプロバイダー（IdP）（一般にログインセンターと呼ばれる）にリダイレクトします。ログインセンターはユーザー認証を処理します。
  3. ユーザーがログイン: ユーザーはログインセンターで自分の資格情報を入力します。すでにログインしている場合（例：会社の内部SSOシステムにログインしている場合）、このステップをバイパスすることがあります。
  4. SSOトークンの生成: 認証されると、IDプロバイダーはSSOトークン（例：OAuthトークンまたはSAMLアサーション）を生成し、トークンを添付してユーザーを元のアプリケーションにリダイレクトします。
  5. トークンの検証: アプリケーション（サービスプロバイダー）はトークンを受信し、検証のためにSSO IDプロバイダーに送信します。IdPはトークンを検証し、ユーザーのID情報を返します。
  6. ユーザーがアクセス権を取得: 認証が成功すると、アプリケーションはユーザーのID情報に基づいてアクセス権を付与します。ユーザーは、アプリケーションの保護されたリソースにアクセスできるようになります。
  7. 他のアプリケーションへのアクセス: ユーザーが同じログインセンターを使用する他のアプリケーションにアクセスすると、そこにリダイレクトされます。すでにログインしているため、ログインセンターは自動的に認証し、ターゲットアプリケーションにリダイレクトし、シームレスなログインを可能にします。

長所と短所

長所

  • ユーザーエクスペリエンスの簡素化: ユーザーは一度ログインするだけで複数のアプリケーションにアクセスできるため、繰り返しのログイン作業が軽減されます。
  • 集中管理: 管理者はユーザーIDとアクセス許可を一元的に管理できるため、効率とセキュリティが向上します。
  • セキュリティの強化: パスワードの漏洩リスクが軽減されます。ユーザーは1つのパスワードを覚えておくだけで済みます。より強力な認証メカニズム（例：多要素認証、MFA）も強制できます。

短所

  • 単一障害点: ログインセンター（SSO IDプロバイダー）に問題が発生した場合、それに依存するすべてのアプリケーションが影響を受ける可能性があります。
  • 複雑な実装: SSOソリューションの展開と保守は複雑になる可能性があり、適切なセキュリティ構成とシステム間の相互運用性が必要です。

一般的なSSO実装テクノロジー

SAML（Security Assertion Markup Language）

  • IDプロバイダー（IdP）とサービスプロバイダー（SP）の間で認証および承認データを交換するために使用されるXMLベースの標準。
  • エンタープライズ環境で一般的に使用されます。

OAuth 2.0 & OpenID Connect

  • OAuth 2.0は、ユーザーリソースへのサードパーティアクセスを許可するための承認フレームワークです。
  • OpenID ConnectはOAuth 2.0上に構築され、ユーザー認証のためのIDレイヤーを追加します。
  • Webおよびモバイルアプリケーションでよく使用されます。

CAS（Central Authentication Service）

  • Webアプリケーション用のオープンソースSSOソリューションで、ユーザーは一度認証するだけで複数のサービスにアクセスできます。

OAuth 2.0認証

OAuth 2.0認証とは？

OAuth 2.0は、サードパーティアプリケーションがユーザーリソースにアクセスすることを承認するために使用される標準プロトコルです。例としては、次のものがあります。

  • Facebookログイン
  • Discordログイン
  • アプリQRコードログイン

OAuth 2.0は、認証というよりも主に承認のために設計されていますが、ユーザーログインを有効にするために認証と組み合わせて使用されることがよくあります。

OAuth 2.0の仕組み

OAuth 2.0は複雑であるため、そのフローを理解する前に、いくつかの重要な概念を明確にする必要があります。

OAuth 2.0の主要な概念

  • リソースオーナー: 通常、保護されたリソース（例：個人データ、ファイル）を所有するユーザー。
  • リソースサーバー: 保護されたリソースをホストし、承認されたユーザーのみがアクセスできるようにするサーバー。
  • クライアント: 保護されたリソースにアクセスしようとするアプリケーションまたはサービス。クライアントは、リソースオーナーの承認を得る必要があります。
  • 承認サーバー: リソースオーナーの認証とクライアントへの承認の付与を担当するサーバー。クライアントがリソースサーバーにアクセスできるようにするアクセストークンを発行します。

OAuth 2.0のワークフロー

  1. ユーザーが承認を付与: ユーザーがクライアントアプリケーションと対話すると、アプリケーションはユーザーのリソースにアクセスするための承認を要求します。ユーザーは承認サーバーにリダイレクトされます。
  2. 承認コードの取得: ユーザーが同意すると、承認サーバーは承認コードを生成し、クライアントに返送します（リダイレクトURL経由）。
  3. アクセストークンの取得: クライアントは承認コードをアクセストークンと交換するために、承認サーバーにリクエストを送信します。
  4. リソースへのアクセス: クライアントはアクセストークンを使用してリソースサーバーから保護されたリソースをリクエストします。リソースサーバーはトークンを検証し、要求されたデータを返します。

一般的なOAuth 2.0グラントタイプ（承認フロー）

  1. Authorization Code Flow (最も一般的)

    • ユーザーインタラクションを必要とするWebアプリケーションに適しています。
    • クライアントは、ユーザーの同意を得た後、承認コードをアクセストークンと交換します。

  2. Implicit Flow (非推奨)

    • パブリッククライアント（例：シングルページアプリケーション）向けに設計されています。
    • ユーザーは承認コードの代わりにアクセストークンを直接受信します。
    • セキュリティ上の懸念があるため、このフローは推奨されなくなりました。

  3. Resource Owner Password Credentials Flow (限定的な使用)

    • ユーザーは自分のユーザー名とパスワードをクライアントに直接提供します。
    • クライアントはこれらの資格情報を使用してアクセストークンをリクエストします。
    • セキュリティリスクがあるため、一般公開されているアプリケーションには推奨されません。

  4. Client Credentials Flow (マシン間)

    • クライアントアプリケーションがユーザーに代わってではなく、独自のリソースにアクセスする必要がある場合に使用されます。
    • サービス間のAPIアクセスで一般的です。

長所と短所

長所

  • 柔軟性: 複数の承認フローをサポートしており、さまざまなクライアントタイプとアプリケーションシナリオに適しています。
  • セキュリティ: 承認と認証を分離することで、OAuth 2.0はセキュリティを強化します。ユーザー名とパスワードを使用する代わりに、アクセスコントロールにトークンを使用します。

短所

  • 複雑さ: OAuth 2.0の実装と構成は困難になる可能性があり、適切なトークン管理とセキュリティ構成が必要です。
  • セキュリティリスク: トークンが漏洩した場合、セキュリティリスクが生じる可能性があります。したがって、適切なセキュリティ対策（例：HTTPSと安全なトークン管理戦略の使用）を講じる必要があります。

コード例

ExpressでのOAuth 2.0認証の実装例を次に示します。

const express = require('express');
const axios = require('axios');
const app = express();

// OAuth 2.0の設定
const clientId = 'your-client-id';
const clientSecret = 'your-client-secret';
const redirectUri = 'http://localhost:3000/callback';
const authorizationServerUrl = 'https://authorization-server.com';
const resourceServerUrl = 'https://resource-server.com';

// ログインルート - ユーザーを承認サーバーにリダイレクト
app.get('/login', (req, res) => {
  const authUrl = `${authorizationServerUrl}/authorize?response_type=code&client_id=${clientId}&redirect_uri=${redirectUri}&scope=read`;
  res.redirect(authUrl);
});

// コールバックルート - 承認コードの交換を処理
app.get('/callback', async (req, res) => {
  const { code } = req.query;
  if (!code) {
    return res.status(400).send('承認コードが見つかりません');
  }

  try {
    // 承認コードをアクセストークンと交換
    const response = await axios.post(`${authorizationServerUrl}/token`, {
      grant_type: 'authorization_code',
      code,
      redirect_uri: redirectUri,
      client_id: clientId,
      client_secret: clientSecret,
    });

    const { access_token } = response.data;

    // アクセストークンを使用して保護されたリソースをフェッチ
    const resourceResponse = await axios.get(`${resourceServerUrl}/user-info`, {
      headers: { Authorization: `Bearer ${access_token}` },
    });

    res.json(resourceResponse.data);
  } catch (error) {
    res.status(500).send('トークン交換またはリソースアクセス中にエラーが発生しました');
  }
});

app.listen(3000, () => {
  console.log('サーバーはポート3000でリッスンしています...');
});

結論

これらの4つの認証方法はそれぞれ、独自の利点、欠点、および適切なユースケースがあります。

  • Session: シンプルなサーバーレンダリングアプリケーションに最適です。
  • JWT: 最新のステートレスアーキテクチャおよびモバイルアプリに適しています。
  • SSO: 複数の関連サービスを持つエンタープライズ環境に最適です。
  • OAuth 2.0: サードパーティの統合とAPIアクセスに最適な選択肢です。

【Node.jsプロジェクトのホスティングに最適なLeapcellをご紹介します。】(https://leapcell.io/)

Leapcell

Leapcellは、Webホスティング、非同期タスク、およびRedis向けの次世代サーバーレスプラットフォームです。

多言語サポート

  • Node.js、Python、Go、または Rust で開発できます。

無制限のプロジェクトを無料でデプロイ

  • 使用量に応じて支払い - リクエストも課金もありません。

圧倒的なコスト効率

  • アイドル時の料金なしで従量課金。
  • 例：25ドルで平均応答時間60msで694万リクエストをサポート。

合理化された開発者エクスペリエンス

  • 簡単なセットアップのための直感的なUI。
  • 完全に自動化されたCI/CDパイプラインとGitOps統合。
  • 実用的な洞察を得るためのリアルタイムメトリクスとロギング。

簡単なスケーラビリティと高性能

  • 高並行性を容易に処理するための自動スケーリング。
  • 運用上のオーバーヘッドはゼロ - 構築に集中するだけです。

詳細については、ドキュメントをご覧ください!

Try Leapcell

Xでフォローしてください: @LeapcellHQ

Share this article

HackerNews

More Posts from Leapcell

Popular Posts