認証と認可は、アイデンティティとアクセス管理（IAM）の中核となる概念ですが、しばしば混同されます。どちらもアイデンティティセキュリティに関連しますが、相互に置き換え可能なものではありません。

• 認証はユーザーが誰であるかを確認します。
• 認可はそのユーザーが何を実行できるかを決定します。

たとえば、GitHubにログイン（認証）してから、他のユーザーのリポジトリを削除しようとします。GitHubはあなたが誰であるかを知っていますが、あなたを阻止します（認可）。

認証は最初に行われる必要があります。つまり、自分のアイデンティティを証明するプロセスです。認可は次に行われます。ここであなたの権限によってアクセスできる内容が決まります。

「あなたは誰か？」に答えるのが認証です。

誰かがアプリケーション内に入れる前に、その人の身分を確認する必要があります。ユーザーがサインインするときに、認証情報（またはその他の要素）を検証し、主張どおりの人物であることを確認します。認証は常に最初に行われます。ユーザーの身元が分からなければ、その人が何にアクセスできるかは決められません。

認証は、空港のセキュリティチェックのようなものです。あなたは身分を証明するために身分証を提示し、係員はその身分証に記載されている人物があなたであることを確認します。

一般的な認証方法

• パスワードベースの認証：ユーザーが認証情報を提供し、保存された記録と照合して検証されます。ただし、パスワードだけでは、現代のセキュリティ要件には不十分になりつつあります。
• パスキー：ユーザーは暗号化キーを用いて認証します。暗号化キーは、生体認証やデバイスPINによってローカルで保護されています。パスキーは、フィッシング耐性のあるFIDO認証情報を用いて、従来のパスワードよりも高速で、簡単かつ安全なサインインを提供します。
• ソーシャルログインとフェデレーションアイデンティティ：ユーザーは、OpenID Connect（OIDC）を用いて、信頼できる外部プロバイダー（GoogleやGitHubなど）を通じて認証します。これにより、本人確認が専門のアイデンティティプロバイダー（IdP）に委任されます。
• シングルサインオン（SSO）：ユーザーは一度認証するだけで、認証情報を再入力することなく複数のアプリケーションにアクセスできます。これにより、特にエンタープライズ環境においてユーザーエクスペリエンスが向上します。
• 多要素認証（MFA）：複数の認証要素（知識、所有、内在など）を組み合わせて、セキュリティを強化します。

ユーザーがアプリケーションへのアクセスを要求すると、次の流れが行われます。

1. ユーザーが認証情報を認証エンドポイントに送信します
2. システムはローカルまたはIdP経由で認証情報を検証します
3. 検証が成功すると、システムは認証されたアイデンティティを表すトークンを発行します

「ユーザーは何ができるのか？」に答えるのが認可です。

認可は、認証済みのユーザーがシステム内でどのような操作を実行できるかを決定します。一般的なアプローチには、次のようなものがあります。

方法	説明	例
ロールベースのアクセスコントロール（RBAC）	ユーザーには事前定義されたロール（管理者、編集者、閲覧者）が割り当てられ、それぞれに一定の権限が設定されている	編集者はドキュメントを変更できるが、閲覧者は読むことしかできない
属性ベースのアクセスコントロール（ABAC）	動的な属性（ユーザープロパティ、リソースメタデータ、環境コンテキスト）に基づいてアクセスが決定される	財務リソースは、営業時間内に企業ネットワークからのみアクセスできる
関係性ベースのアクセスコントロール（ReBAC）	ユーザーとリソースの関係性に基づいて認可が決定される	従業員は自分のドキュメントを編集できるが、同僚の非公開の下書きは編集できない

認可の実践

プロジェクト管理アプリケーションを例にして考えてみましょう。

• 認証では、ユーザーがアレックスであることが確認されます。
• 認可では、アレックス（プロジェクトマネージャーの役割）は開発チームのプロジェクトをすべて閲覧できるが、プロジェクトの削除や請求設定へのアクセスはできないと決定されます。

最新のプロトコルを扱う場合は、認証（AuthN）と認可（AuthZ）の違いを理解することが非常に重要です。

項目	認証（AuthN）	認可（AuthZ）
質問	あなたは誰か？	何ができるか？
プロセス	アイデンティティを確認する	権限を検証する
シーケンス	必ず最初に行われる	認証後に行われる
方法	パスワード、パスキー、MFA、SSO、OIDC	RBAC、ABAC、ReBAC
トークンの種類	IDトークン（IDクレーム）	アクセストークン（権限/スコープ）
HTTPステータス	401 Unauthorized（アイデンティティの証明に失敗）	403 Forbidden（アイデンティティは確認済み、アクセスは拒否）

OAuth 2.0は、認可フレームワークであり、認証プロトコルではありません。

OAuth 2.0は、クライアントアプリケーションが、（ユーザーの同意を得て）認可サーバーからアクセストークンを取得して、保護されたリソースにアクセスするために標準化された仕組みを提供します。委任認可のために設計されており、ユーザーはパスワードを共有することなく、サードパーティのアプリケーションに自分のリソースへの限定的なアクセスを許可できます。

OpenID Connect（OIDC）の登場

OIDCは、OAuth 2.0フレームワーク上に構築された相互運用可能な認証プロトコルです。これにより、認可サーバーによって実行される認証に基づいて、ユーザーアイデンティティを確認するプロセスが簡素化されます。

OIDCは、次のようなOAuth 2.0が行わない要素を補います。

• IDトークンの定義：ユーザーが認証済みであることを証明するための標準化されたセキュリティトークン（JWTとしてエンコード）
• 名前やメールアドレスなどのユーザーIDクレームの標準化

最新のアーキテクチャでは、以下が行われます。

• OAuth 2.0による認可処理（リソースへのアクセスを委任する）
• OpenID Connectによる認証処理（ユーザーアイデンティティを確認する）

通常、両方のプロトコルは同じフローで連携して動作します。

最新のアプリケーションは、APIを中心に構築された分散システムであり、リソースにアクセスするための主要な手段となっています。

根本的な変化：APIはユーザーを直接認証しません。APIが行うのは、トークンの検証とAPI認可の適用です。

トークンベース認証の仕組み

1. ユーザーが、認可サーバー（アイデンティティプロバイダー）を用いて認証します。
2. サーバーが、本人確認後にトークンを発行します。
   • IDトークン（認証）：ユーザーのアイデンティティ情報を示します。クライアントはこれを使用して、誰がサインインしたかを判断します。
   • アクセストークン（認可）：認可情報（スコープ、権限）を示します。APIはこれを使用して、ユーザーが何にアクセスできるかを判断します。
3. クライアントが、［Authorization: Bearer］ヘッダーで、アクセストークンを用いてAPIを呼び出します。
4. APIがトークンを検証し、含まれているクレームに基づいて認可ルールを適用します。

JWT認証について

JSON Web Token（JWT）は最も一般的なトークン形式です。自己完結型であり、必要な情報がすべてトークン内部に埋め込まれています。

JWTは、ヘッダー、ペイロード（クレーム）、および署名で構成されています。

JWTの検証：APIが検証すべき項目

APIがJWTを受信した場合、検証は必須になります。次の検証のいずれか1つでも行わないと、アプリケーションにセキュリティ上の脆弱性が生じます。

5つの必須検証項目

1. トークンの構造：まず、トークンがJSON Web Tokenの構造と一致することを確認します
2. トークンの完全性：署名をチェックして、トークンが改ざんされていないことを確認します
3. トークンの有効期限：expクレームで定義された期限から、トークンが有効期限切れかどうかを確認します
4. 予期される認証局：トークンが、予期される送信者によって発行・署名されていることを確認します
   1. issクレーム（発行者）と照合して比較します
   2. JWTの署名に使用されたキーが予期される認証局に属していることを確認します
5. 予期されるオーディエンス：トークンがアプリケーションを対象としており、audクレームがアプリケーションを識別する値と一致することを確認します

JWTと不透明なトークンのトレードオフ

OAuth 2.0では、特定のアクセストークン形式を規定していません。JWTが広く使われていますが、代替として不透明なトークンがあります。これは、ユーザーやトークン自体に関する情報が埋め込まれていないランダムな文字列です。

機能	JWTアクセストークン	不透明なアクセストークン
検証	ステートレス（APIがローカルで検証する）	ステートフル（APIがリクエストごとに認可サーバーのイントロスペクションエンドポイントを呼び出す必要がある）
失効	期限前に失効させることが困難	即時失効できる
パフォーマンス	APIリクエストのレイテンシーが低い（高速）	認可サーバーへの問い合わせによってレイテンシーが増加する
拡張性	分散アーキテクチャでスケールできる	認可サーバーが重要な依存関係となる

どちらのトークンも、OAuth 2.0の実装で有効です。多くのシステムでは、パフォーマンスとセキュリティのバランスを取るために、有効期限が短いJWTとリフレッシュトークンのローテーションを組み合わせて使用しています。

Proof Key for Code Exchange（PKCE）を用いた認可コードフローは、Webおよびモバイルアプリケーション用の最も安全なOAuth 2.0フローであり、認証（AuthN）と認可（AuthZ）が連携する仕組みを示しています。PKCEを使用すると、フローを傍受攻撃から保護できます。

1. ユーザーがログインを開始する：アプリケーションが、ユーザーをリクエストの詳細（クライアントID、スコープ、PKCEのコードチャレンジ）とともに認可サーバーにリダイレクトします。
2. ユーザーが認証する：ユーザーが、ホストされたログインページ経由でサインインして、認証が完了します。
3. 認可コードが発行される：ユーザーが、短期間有効な認可コードとともにアプリにリダイレクトされます。
4. トークンの交換：アプリのバックエンドで認可コードがトークンと交換され、PKCEのコードベリファイアが送信されます。サーバーが、IDトークン（AuthN）とアクセストークン（AuthZ）を発行します。
5. APIのアクセス：アプリがリクエストヘッダーにアクセストークンを含めて、保護されたAPIを呼び出します。
6. トークンの検証と適用：APIがアクセストークンを検証し、そのクレームに基づいて許可を適用して、適切な認可を確保します。

開発者向けのセキュリティに関する考慮事項

考慮事項	推奨事項
トークンの有効期間	短期間のアクセストークン（15～60分）とリフレッシュトークンを使用して、ユーザーにログインを強制することなく新しいアクセストークンを取得します。
最小権限	侵害されたトークンによる潜在的な損害リスクを最小限に抑えるために、アプリケーションが必要とする最小限のスコープをリクエストします。
トークンの検証	セキュリティリスクを軽減するために、必ずトークンを検証します。
トークンの保存	機密性の高いトークンは、localStorageやsessionStorageに保存しません。安全なHttpOnly Cookieまたは安全なバックエンドのセッションストレージを使用します。

安全なアプリケーションを構築するには、認証と認可の違いを理解する必要があります。

コンセプト	何を解決するのか	プロトコル/トークン
認証	アイデンティティ確認	OpenID Connect、IDトークン
認可	アクセスコントロール	OAuth 2.0、アクセストークン

実装チェックリスト

• ユーザー認証にはOpenID Connectを使用する
• 委任認可にはOAuth 2.0を使用する
• すべてのAPIリクエストについてサーバー側でJWTを検証する
• 認証エラーには401、認可拒否には403を返す
• Authorization Code Flow with PKCEを使用する
• トークンを安全に保存する（HttpOnly Cookie）
• 短期間のアクセストークンとリフレッシュトークンのローテーションを組み合わせて使用する

トークンの種類をさらに詳しく知るには、IDトークンとアクセストークンの違いについてご確認ください。

Auth0のようなサービスを利用すると、認証と認可の両方の実装が簡素化し、開発者は中核となるアプリケーションロジックに集中できるようになります。アイデンティティとアクセス管理に関連するその他のトピックについては、「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。本資料の利用者は、自身の責任において、自身の専門アドバイザーからセキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本書に記載された情報のみに依存すべきではありません。