認証と認可入門：Webセキュリティの基本を理解しよう（入門編） | First byte Blog

認証と認可入門：Web セキュリティの基本を理解しよう

はじめに

Web サイトやアプリを利用するとき、「ログイン」は当たり前の操作になっています。メールアドレスとパスワードを入力したり、Google アカウントでログインしたりすることで、私たちは自分のアカウント情報にアクセスしたり、特定の機能を使ったりできます。

この「ログイン」の裏側で働いているのが、認証と認可というセキュリティの基本概念です。

この記事では、認証と認可とは何か、なぜ重要なのか、そしてどのような仕組みで実現されているのかを、初心者にもわかりやすく解説します。

認証（Authentication）とは？

認証の定義

認証（Authentication）とは、「あなたが誰であるかを確認する」プロセスです。

例えるなら、認証は建物の入口での身分証明書の提示です：

あなたが「私は山田太郎です」と名乗る（ユーザー ID の入力）
受付係が身分証明書（パスワードやその他の証明手段）の提示を求める
あなたが有効な身分証明書を提示する
受付係が「確かに山田太郎さんですね」と確認する

Web サービスにおける認証は、あなたが本当にアカウントの持ち主であることを確認する手続きです。

なぜ認証が必要か？

不正アクセスの防止：なりすましを防ぎ、アカウントの所有者だけがアクセスできるようにする
個人情報の保護：他人に個人情報や設定を見られないようにする
機能の制限：登録ユーザーのみが利用できる機能を提供する

認可（Authorization）とは？

認可の定義

認可（Authorization）とは、「あなたが何をしてよいか（アクセス権限）を決定する」プロセスです。

認証が「誰であるか」を確認するのに対し、認可は「何ができるか」を決定します。

先ほどの建物の例えで続けると：

認証によって建物に入ることを許可された（ログイン成功）
あなたは「一般エリアには入れますが、役員室には入れません」と言われる（権限の付与）

Web サービスにおける認可は、ログインしたユーザーがどのデータにアクセスでき、どの機能を利用できるかを制御する仕組みです。

なぜ認可が必要か？

権限管理：ユーザーの種類（管理者、一般ユーザー、ゲストなど）に応じてアクセスできる範囲を制御する
データ保護：他のユーザーのデータや、自分に関係のない情報へのアクセスを防ぐ
機能制御：有料プランのユーザーのみが特定の機能を使えるようにするなど、サービスの提供レベルを管理する

認証と認可の違い（まとめ）

観点	認証 (Authentication)	認可 (Authorization)
目的	ユーザーが誰であるかを確認	ユーザーが何をしてよいか決定
タイミング	通常、ログイン時に行われる	ログイン後、各操作時に行われる
例	パスワード入力、指紋認証	ファイルへのアクセス権確認
質問	「あなたは誰ですか？」	「あなたは何ができますか？」

認証は認可の前に行われます。 まず本人確認（認証）をしてから、その人に何をする権限があるか（認可）を確認するという順番です。

一般的な認証方法

Web サービスでよく使われる認証方法をいくつか紹介します。

1. パスワード認証

最も基本的な認証方法で、ユーザー名（またはメールアドレス）とパスワードの組み合わせで本人確認を行います。

メリット：実装が比較的簡単、ユーザーに馴染み深い
デメリット：パスワードの漏洩、使い回し、簡単なパスワード設定などのリスクがある

パスワードの安全な管理方法：

パスワードはそのまま保存せず、ハッシュ化（元に戻せないように変換）して保存する
ソルト（ユーザーごとに異なるランダムな文字列）を加えてハッシュ化することで、同じパスワードでも異なるハッシュ値になるようにする

// パスワードハッシュ化の簡単なイメージ（実際は専用ライブラリを使用）
const crypto = require("crypto");

function hashPassword(password, salt) {
  return crypto.createHmac("sha256", salt).update(password).digest("hex");
}

const salt = crypto.randomBytes(16).toString("hex"); // ユーザーごとに生成・保存
const hashedPassword = hashPassword("mysecretpassword", salt);

2. 多要素認証（MFA）

複数の異なる認証要素を組み合わせてセキュリティを高める方法です。一般的には以下の 3 つの要素のうち、2 つ以上を組み合わせます：

知識要素：ユーザーが知っている情報（パスワード、PIN コード）
所有要素：ユーザーが持っているもの（スマートフォン、ハードウェアトークン）
生体要素：ユーザー自身の身体的特徴（指紋、顔、虹彩）

例：

パスワード入力後に、SMS で送られてくる確認コードを入力する
パスワード入力後に、認証アプリ（Google Authenticator など）が生成するワンタイムパスワードを入力する
指紋認証や顔認証でログインする

3. ソーシャルログイン

Google、Facebook、Twitter などの既存アカウントを利用してログインする方法です。OAuth 2.0 という技術が使われることが多いです（後述）。

メリット：ユーザーは新しいパスワードを覚える必要がない、登録の手間が省ける
デメリット：連携先のサービスに依存する、プライバシーに関する懸念

4. 生体認証

指紋、顔、虹彩、声紋など、個人の生体情報を使って認証する方法です。

メリット：パスワードを覚える必要がない、なりすましが困難
デメリット：専用のデバイスが必要、認証精度やプライバシーの問題

一般的な認可方法

ユーザーにどのような権限を与えるかを決定する一般的な方法です。

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

ユーザーに「ロール（役割）」を割り当て、そのロールに基づいて権限を付与する方法です。

例：

管理者ロール：全機能へのアクセス権限
編集者ロール：記事の作成・編集権限
閲覧者ロール：記事の閲覧権限のみ

メリット：管理が比較的シンプル
デメリット：細かい権限設定が難しい場合がある

2. 属性ベースアクセス制御（ABAC）

ユーザーの属性（部署、役職など）、リソースの属性（ファイルの機密レベルなど）、環境（アクセス時間、場所など）に基づいて、より動的に権限を決定する方法です。

例：「人事部のマネージャー」は「勤務時間内」に「部下の勤怠情報」にアクセスできる
メリット：非常に柔軟で細かい権限設定が可能
デメリット：ルールの設計や管理が複雑になる可能性がある

認証・認可を実現する技術

Web アプリケーションで認証・認可を実現するためによく使われる技術や概念を簡単に紹介します。

1. セッションとクッキー

セッション：ユーザーがログインしてからログアウトするまでの一連の操作期間。サーバー側でユーザーの状態（ログインしているかどうかなど）を管理します。
クッキー：ブラウザに保存される小さなデータ。サーバーはログイン成功時にセッション ID を生成し、それをクッキーに保存してブラウザに送ります。ブラウザは次回以降のリクエストでクッキー（セッション ID）をサーバーに送り、サーバーはそれを見てログイン済みユーザーであることを認識します。

クライアント <-- セッションIDをクッキーに保存 <-- サーバー
クライアント --> クッキー(セッションID)を送信 --> サーバー (セッションIDを検証)

2. トークンベース認証

セッションの代わりに「トークン」を使用する認証方式です。特に、API 連携やシングルページアプリケーション（SPA）でよく利用されます。

サーバーはログイン成功時にトークンを発行し、クライアントに渡します。
クライアントは以降のリクエストでトークンをヘッダーなどに含めて送信します。
サーバーはトークンを検証してユーザーを認証します。

3. JWT（JSON Web Token）

JWTは、トークンベース認証でよく使われるトークンの形式です。JSON 形式のデータに電子署名を付加したもので、改ざんを検知できます。

構造：ヘッダー、ペイロード（ユーザー情報など）、署名の 3 つの部分から構成される
特徴：自己完結型（トークン自体に必要な情報が含まれる）、ステートレス（サーバー側でセッションを管理する必要がない場合がある）

// JWTの例 (実際はBase64エンコードされています)
Header.Payload.Signature

// ペイロードの例
{
  "sub": "1234567890", // ユーザーID
  "name": "John Doe",
  "iat": 1516239022, // 発行時刻
  "exp": 1516242622, // 有効期限
  "roles": ["admin", "editor"]
}

4. OAuth 2.0

OAuth 2.0は、「認可」のための標準的なプロトコルです。あるサービス（例：あなたのアプリ）が、ユーザーの許可を得て、別のサービス（例：Google）のリソース（例：連絡先リスト）にアクセスするための仕組みです。

ポイント：ユーザーのパスワードを直接扱わずに、限定的なアクセス権（トークン）を取得する。
使われ方：ソーシャルログイン、「〇〇アプリに Google ドライブへのアクセスを許可しますか？」のような連携機能。

5. OpenID Connect (OIDC)

OpenID Connectは、OAuth 2.0 を拡張して「認証」機能を追加したプロトコルです。

OAuth 2.0 で認可（アクセストークン取得）を行う過程で、ユーザーの身元情報（ID トークン）も取得できるようにします。
ソーシャルログインの多くは OIDC に基づいています。

セキュリティに関するベストプラクティス

HTTPS の使用：通信経路を暗号化する
パスワードポリシーの強化：複雑さの要件、定期的な変更推奨
多要素認証（MFA）の導入：パスワード漏洩時のリスクを低減
セッション管理の徹底：セッション ID の推測困難化、タイムアウト設定
トークンの適切な管理：有効期限の設定、安全な保存場所
最小権限の原則：ユーザーには必要最低限の権限のみを付与する
ライブラリ・フレームワークの活用：セキュリティ機能が組み込まれた信頼できるものを使用する
定期的な脆弱性診断

認証と認可の要点（Webセキュリティの根幹）

認証と認可は、Web サービスやアプリケーションのセキュリティを支える根幹となる概念です。

認証は「あなたが誰か」を確認するプロセス
認可は「あなたに何ができるか」を決定するプロセス

パスワード認証から多要素認証、ソーシャルログインまで、様々な認証方法があります。また、RBAC や ABAC といった方法でアクセス権限を管理します。

セッション、クッキー、トークン（JWT）、OAuth 2.0、OpenID Connect などの技術が、これらの仕組みを実現するために使われています。

安全な Web サービスを構築・利用するためには、これらの基本的な仕組みを理解し、適切なセキュリティ対策を講じることが不可欠です。

認証・認可システムについてのご相談はこちら

認証と認可入門：Webセキュリティの基本を理解しよう