認証と認可の違いとは？【図解でわかりやすく解説】

認証と認可の違いを一言でいうと？
認証（Authentication）とは？
1. 認証の特徴
2. 認証の使いどころ
認可（Authorization）とは？
1. 認可の特徴
2. 認可の使いどころ
認証と認可の違いを比較表でチェック
どっちを重視すべき？シーン別おすすめ
1. 認証を特に強化すべきケース
2. 認可を特に強化すべきケース
まとめ

認証と認可の違いを一言でいうと？

結論から言えば、認証（Authentication）は「あなたは誰？」を確認すること、認可（Authorization）は「あなたは何ができる？」を確認することです。

たとえば、会社のオフィスビルに入る場面を想像してください。入口で社員証を見せて本人確認をするのが「認証」です。そして、社員証で3階の開発フロアには入れるが、5階の役員フロアには入れないという権限チェックが「認可」にあたります。

Web開発の現場では、この2つの概念は常にセットで登場します。ログイン機能を実装するとき、APIのアクセス制御を設計するとき、どちらか一方だけでは安全なシステムは作れません。この記事では、認証と認可の違いをコード例付きで徹底解説します。

認証（Authentication）とは？

認証（Authentication、略称: AuthN）は、ユーザーが主張する「自分が誰であるか」を検証するプロセスです。英語では「AuthN」と略されることが多く、セキュリティの文脈で頻繁に登場します。

認証の特徴

認証では、以下の「3つの要素」のいずれか（または組み合わせ）で本人確認を行います。

知識情報（Something you know）: パスワード、PINコード、秘密の質問
所持情報（Something you have）: スマートフォン、セキュリティキー、ICカード
生体情報（Something you are）: 指紋、顔認証、虹彩認証

最近のWebサービスでは、パスワードだけの「単一要素認証」からこれらを組み合わせた多要素認証（MFA）への移行が進んでいます。たとえば、パスワード入力後にスマートフォンへ送信されるワンタイムコードを入力する方式がこれにあたります。

認証の使いどころ

認証が使われる代表的な場面を見てみましょう。

Webサービスのログイン画面
APIリクエスト時のトークン検証
SSO（シングルサインオン）でのID連携

実務では、JWT（JSON Web Token）を使った認証が広く使われています。以下はNode.jsでJWTを発行する基本的なコード例です。

const jwt = require('jsonwebtoken');

// ログイン成功後にトークンを発行（認証の完了）
function issueToken(userId) {
  const payload = { sub: userId, iat: Math.floor(Date.now() / 1000) };
  return jwt.sign(payload, process.env.JWT_SECRET, { expiresIn: '1h' });
}

// リクエスト時にトークンを検証（認証の確認）
function verifyToken(token) {
  try {
    return jwt.verify(token, process.env.JWT_SECRET);
  } catch (err) {
    throw new Error('認証に失敗しました');
  }
}

このように、認証はあくまで「誰であるか」を確認するだけであり、「何ができるか」は認可の領域です。Webサービスにおける認証の仕組みをより深く理解するには、CookieとSessionの違いも合わせて知っておくと実装時に役立ちます。

認可（Authorization）とは？

認可（Authorization、略称: AuthZ）は、認証済みのユーザーに対して、特定のリソースや操作へのアクセスを許可するプロセスです。認証が「身元確認」なら、認可は「権限チェック」と考えるとわかりやすいでしょう。

認可の特徴

認可には、主に以下のようなアクセス制御モデルが使われます。

RBAC（Role-Based Access Control）: ユーザーの「役割」に基づいてアクセス権限を管理する方式。管理者・編集者・閲覧者などの役割を定義する
ABAC（Attribute-Based Access Control）: ユーザーの属性（部署、勤務地、時刻など）に基づいて動的に権限を判定する方式
スコープベース: OAuthでよく使われる。APIへのアクセスに対して「read」「write」「admin」などのスコープ（範囲）で制御する

認可の使いどころ

認可が必要になる代表的な場面です。

管理者だけがユーザー削除できるダッシュボード
OAuth 2.0で「Googleドライブの読み取り専用アクセス」を許可する
APIのエンドポイントごとに必要な権限レベルを設定する

Express.jsでRBACを実装する簡単な例を見てみましょう。

// 認可ミドルウェア（RBACの実装例）
function authorize(...allowedRoles) {
  return (req, res, next) => {
    // req.user は認証ミドルウェアでセット済み
    if (!req.user) {
      return res.status(401).json({ error: '認証が必要です' });
    }
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({ error: '権限がありません' });
    }
    next();
  };
}

// 使い方: 管理者のみアクセス可能なエンドポイント
app.delete('/api/users/:id', authorize('admin'), (req, res) => {
  // ユーザー削除処理
});

ここで注目すべきは、HTTPステータスコードです。認証の失敗は401 Unauthorized、認可の失敗は403 Forbiddenを返します。この使い分けは、GETとPOSTの違いと同様に、HTTP仕様を正しく理解するうえで重要なポイントです。

認証と認可の違いを比較表でチェック

比較項目	認証（Authentication）	認可（Authorization）
英語略称	AuthN	AuthZ
問いかけ	あなたは誰ですか？	あなたは何ができますか？
目的	本人確認・身元検証	アクセス権限の付与・確認
実行タイミング	認可より先に実行される	認証の後に実行される
失敗時のHTTPステータス	401 Unauthorized	403 Forbidden
代表的なプロトコル	OIDC、SAML、FIDO2/WebAuthn	OAuth 2.0、XACML
実装例	ログイン画面、パスワード認証、MFA	ロールベースのアクセス制御、APIスコープ