認証と認可の違い（Authentication vs Authorization）

認証（Authentication）と認可（Authorization）とは？

ITシステムやセキュリティの世界において、最も基本でありながら混同されやすい概念が「認証（Authentication）」と「認可（Authorization）」です。この二つは明確に異なる役割を持っており、安全なシステムを設計・運用するためには、その違いを正しく理解し、適切に組み合わせることが不可欠です。

認証（Authentication）：あなたは誰か？

認証とは、「通信の相手が、名乗っている通りの本人であるかを確認するプロセス」のことです。英語では Authentication と呼ばれ、しばしば AuthN と略されます。

日常の例で例えるなら、空港の入国審査で「パスポートを提示する」行為に似ています。パスポートには顔写真と名前が記載されており、審査官はそれを見て「あなたが誰であるか」を特定し、本人であることを確認します。

ITシステムにおける認証の代表的な例は以下の通りです。

• パスワード認証: ユーザーIDとパスワードの組み合わせによる確認。
• 生体認証（バイオメトリクス）: 指紋や顔認証など、ユーザーの身体的特徴を用いた確認（スマートフォン等のロック解除など）。
• 多要素認証（MFA）: パスワードに加えて、SMSで送られてくるワンタイムパスワード（OTP）などを組み合わせる強固な確認方法。

認可（Authorization）：あなたは何ができるか？

一方、認可とは、「特定の条件を満たす（認証済みの）ユーザーに対して、特定のリソースへのアクセスや操作権限を与えるプロセス」のことです。英語では Authorization と呼ばれ、AuthZ と略されることがあります。

再び空港の例で例えましょう。「ビザ（査証）」や「搭乗券」が認可に該当します。パスポートであなたが誰であるかは証明できても、その国の特定のエリアに入ったり、特定の飛行機に乗るためには「許可（チケット）」が必要です。

ITシステムにおける認可の例は以下の通りです。

• ファイルへのアクセス権限: 会社の共有フォルダで、「社員Aは読み取り専用」「管理者の社員Bは読み書き可能」といった権限設定。
• Webサービスのプラン: 無料会員は一部の記事のみ読めるが、有料会員はすべての記事を読める、といった機能の制御。

認証と認可はなぜ混同されやすいのか？

この二つが混同されやすい最大の理由は、実際の多くのシステム（例えば社内システムへのログインなど）において、これらが「同時に」行われているように見えるためです。ユーザーがIDとパスワードを入力してログイン（認証）すると、自動的に自分のデータにアクセスできる状態（認可）になるため、裏側の仕組みを意識する機会が少ないのです。

しかし、現代の複雑なWebアプリケーションやAPIエコシステムにおいては、この二つを分離して管理することが重要視されています。

OAuth 2.0 と OpenID Connect (OIDC) の関係

認証と認可の違いを理解する上で、最も重要な技術標準が「OAuth 2.0」と「OpenID Connect (OIDC)」です。

• OAuth 2.0: これは純粋な 「認可」 のためのプロトコルです。例えば、「あるアプリが、あなたの代わりにGoogleカレンダーに予定を追加する権限」を与えるための仕組みです。
• OpenID Connect (OIDC): これはOAuth 2.0を拡張して作られた 「認証」 のためのプロトコルです。GoogleやAppleのIDを使って他のサービスにログインする（シングルサインオン）機能を提供します。

かつてはOAuth 2.0を無理やり認証に使おうとする（いわゆる「疑似認証」）ケースがあり、セキュリティ上の脆弱性を生んでいました。現在では、認証にはOIDC、APIアクセスなどの認可にはOAuth 2.0を使うという使い分けがベストプラクティスとなっています。

まとめ

• 認証 (AuthN) は「Who are you?（あなたは誰か）」。本人確認を行うプロセスです。
• 認可 (AuthZ) は「What can you do?（何ができるか）」。権限を付与するプロセスです。

この二つの違いを意識することは、安全なデジタルサービスの設計や、最新のアイデンティティ技術（SSOやフェデレーションなど）を理解する上での重要な第一歩となります。

参考URL: NIST SP 800-63 Digital Identity Guidelines (デジタルアイデンティティの国際基準)