「認証」と「認可」の違いとは？Authentication・Authorization・OAuthも解説

「ユーザーを認証する」

「アクセスを認可する」

IT・Webサービスの説明では、「認証」と「認可」というよく似た言葉が登場します。

特にログインやAPI、OAuthについて調べていると、

「認証と認可は何が違う？」

「ログインは認証？認可？」

「パスワードを確認するのはどちら？」

「ログインできたのに管理画面を開けないのはなぜ？」

「OAuthは認証の仕組みではないの？」

「AuthenticationとAuthorizationはどちらがどちら？」

と迷うことがあります。

結論からいうと、「認証」は『あなたは誰なのか』を確認すること、「認可」は『その人に何をする権限があるのか』を判断することです。

一言で覚えるなら、

認証＝「あなたは誰？」

認可＝「あなたは何をしてよい？」

です。

たとえば会社のシステムに、社員AさんがIDとパスワードでログインしたとします。

システムが、

「この利用者は本当に社員Aさんである」

と確認するのが「認証」です。

その後、

「社員Aさんは一般社員なので、自分の勤怠情報は見られるが、人事管理画面は開けない」

と判断するのが「認可」です。

NIST（米国国立標準技術研究所）はAuthenticationを、ユーザー・プロセス・デバイスなどの身元を確認することと説明しています。

一方、Authorizationは、ユーザー・プログラム・プロセスなどへアクセス権限を付与すること、または特定リソースへのアクセスを許可・拒否する判断として定義しています。

Microsoftも、Authenticationは「本人であることを証明すること」、Authorizationは「認証された主体に何をする権限があるかを決めること」と整理しています。

この記事では、「認証」と「認可」の基本的な違いから、ログイン、アクセス権限、OAuth 2.0、OpenID Connect、アクセストークン、IDトークン、RBACとの関係まで詳しく解説します。

「認証」と「認可」の違い【結論】

比較項目	認証	認可
英語	Authentication	Authorization
略称	AuthN	AuthZ
確認すること	「あなたは誰か」	「何をしてよいか」
代表例	パスワード、パスキー、多要素認証などによる本人確認	閲覧・編集・削除・管理などの権限判定
一般的な順序	先に行われることが多い	認証後の主体に対して行われることが多い
失敗すると	本人確認できずログインできない	本人確認済みでも対象機能へアクセスできない
関連技術の例	OpenID Connect、WebAuthnなど	OAuth 2.0、RBAC、アクセス制御など

3秒で判断するなら、

「本人なのか確かめている？」 → 認証

「その本人に操作を許してよいか判断している？」 → 認可

と考えてください。

「認証」とは？

利用者が「本当にその本人なのか」を確認すること

IT分野における「認証」は、利用者・デバイス・システムなどが、名乗っている主体本人であることを確認する処理です。

英語では、

Authentication

といいます。

Microsoftでは略して、

AuthN

と表記されることがあります。

NISTはAuthenticationについて、ユーザー、プロセス、デバイスなどの身元を検証し、システムリソースへのアクセスを許可する前提となる処理として説明しています。

認証には何を使う？

本人確認には、さまざまな認証手段が利用されます。

代表例には、

• パスワード
• PIN
• パスキー
• ワンタイムパスワード
• 認証アプリ
• セキュリティキー
• 指紋認証
• 顔認証

などがあります。

また、一つの認証手段だけではなく、異なる種類の要素を組み合わせる、

多要素認証（MFA）

も広く利用されています。

ログインは「認証」なの？

一般的なWebサービスのログインでは、認証が中心的な役割を持ちます。

たとえば、

1. ユーザー名を入力する
2. パスワードを入力する
3. システムが認証情報を確認する
4. 本人と確認できればログイン状態になる

という流れです。

この、

「入力された情報を使って利用者の本人性を確認する」

部分が認証です。

ただし、ログイン処理全体には、認証後のセッション作成やアクセス制御など別の仕組みが含まれる場合もあります。

そのため、

「ログインという操作全体＝認証だけ」

と厳密に同一視するより、ログインの重要な処理の一つが認証だと考えると分かりやすいでしょう。

「認可」とは？

認証された主体に「何を許可するか」を決めること

IT分野における「認可」は、ユーザー・アプリ・サービスなどに対して、

どのリソースへアクセスできるか

どの操作を実行できるか

を決めることです。

英語では、

Authorization

といいます。

Microsoftでは略して、

AuthZ

と表記することがあります。

NISTはAuthorizationについて、ユーザー・プログラム・プロセスへアクセス権限を付与することや、システムのデータ・アプリ・サービスなどへのアクセスを許可または拒否する判断として説明しています。

認可の代表例

たとえば会社のファイル共有システムで、

• 一般社員は閲覧のみ可能
• 担当者は編集可能
• 管理者は削除も可能

というルールが設定されているとします。

この、

「誰にどこまでの操作を許すのか」

という制御が認可です。

認証と認可は通常どちらが先？

一般的なシステムでは、

認証 → 認可

という順序になることが多いでしょう。

まず、

「あなたは誰なのか」

を確認します。

その後、その利用者について、

「どの操作を許してよいのか」

を判断します。

NISTの資料でも、Authorizationは通常Authenticationの後に付与されるものとして説明されています。

ただしシステム設計によっては、匿名利用者へ一部のリソースを許可するなど、必ずしもすべての認可判断に個人を特定する認証が必要とは限りません。

「認証できた＝何でもできる」ではない

認証に成功したからといって、システム内のすべての情報を見たり変更したりできるわけではありません。

たとえば社員Aさんが正常にログインできても、

• 自分の勤怠情報は閲覧可能
• 他社員の給与情報は閲覧不可
• システム設定は変更不可

ということがあります。

社員Aさん本人であることは認証済みです。

しかしアクセスしようとしているデータへの権限がないため、

認可されない

ということです。

認証と認可を「ホテル」で例えると？

ホテルを例にすると分かりやすくなります。

フロントで身分証明書や予約情報を確認して、

「あなたは予約した本人です」

と確認するのが、

認証

です。

その後、渡されたカードキーで、

「あなたの部屋には入れるが、他人の部屋には入れない」

ようにするのが、

認可

です。

本人確認が済んでも、ホテル内のすべての部屋に入れるわけではありません。

この例を覚えておくと、両者の違いを理解しやすいでしょう。

認証と認可を「会社」で例えると？

会社へ入るときに社員証を使い、

「この人物は会社の社員である」

と確認するのが認証です。

その社員証を使って、

• 一般オフィスには入れる
• サーバールームには入れない
• 役員フロアには入れない

などとアクセス範囲を制御するのが認可です。

「認証」と「認可」の決定的な違い

違い1：確認している内容が違う

認証＝主体の身元を確認

認可＝主体の権限を確認

です。

ここが最も重要な違いです。

違い2：認証情報と権限情報は別

認証では、

• パスワード
• パスキー
• 認証器

などを使って本人確認を行います。

認可では、

• ユーザーの役割
• アクセス権限
• グループ
• ポリシー
• 許可された操作

などを基にアクセスを判断します。

違い3：成功・失敗したときの結果が違う

認証に失敗すると、

「あなたが誰なのか確認できない」

ため、一般にはログインできません。

認可に失敗すると、

「本人確認はできているが、その操作をする権限がない」

状態になります。

「アクセス制御」と「認可」の違い

認可と密接に関係する言葉が、

アクセス制御（Access Control）

です。

NISTではAuthorizationの定義として、システムオブジェクトへのアクセスを許可・拒否する判断をAccess Controlと関連付けています。

一般的には、

認可＝どのアクセスを許可するか決定すること

アクセス制御＝その権限ルールを実際に適用してアクセスを制御する仕組み

と整理すると分かりやすいでしょう。

「権限」と「認可」の違い

「権限」は、その利用者が持っている許可内容です。

たとえば、

• 閲覧権限
• 編集権限
• 削除権限
• 管理者権限

などがあります。

認可は、これらの権限を基に、

「この操作を許すか、拒否するか」

を決定するプロセスです。

「管理者」と「一般ユーザー」の違いも認可？

多くの場合、認可・アクセス制御と関係します。

たとえば同じシステムへログインしていても、

一般ユーザー

には自分の情報だけを編集できる権限を与え、

管理者

には全ユーザーを管理できる権限を与えることがあります。

どちらのユーザーも認証には成功しています。

違うのは、認可された操作の範囲です。

「RBAC」とは？

アクセス権限を管理する代表的な考え方に、

RBAC（Role-Based Access Control）

があります。

日本語では、

「ロールベースアクセス制御」

などと呼ばれます。

ユーザー一人ひとりへ個別に権限を付与するのではなく、

• 一般社員
• 課長
• 人事担当者
• システム管理者

などの「役割（Role）」へ権限を設定し、ユーザーへ役割を割り当てる方式です。

このようなアクセス制御も認可と密接に関係します。

「OAuth 2.0」は認証？認可？

ここは特に混同されやすいポイントです。

OAuth 2.0は基本的に「認可」のためのフレームワークです。

IETFのRFC 6749では、OAuth 2.0について、第三者アプリケーションがHTTPサービスへ限定的なアクセスを取得できるようにする、

Authorization Framework

と明記されています。

OAuth公式サイトも、

「OAuth is an authorization protocol」

と説明しており、OAuth単独では利用者が誰なのかを示す認証プロトコルではないとしています。

OAuthを具体例で理解する

たとえば、写真印刷サービスが、あなたのクラウドストレージに保存されている写真へアクセスしたいとします。

このとき、クラウドサービスのパスワードを写真印刷サービスへ渡すのは安全ではありません。

OAuthを利用すれば、

「このアプリには写真の読み取りだけを許可する」

といった限定的なアクセス権を与えられます。

重要なのは、

「あなたのパスワードを第三者アプリへ渡すこと」

ではなく、

「第三者アプリへどこまでアクセスを許すか」

だということです。

これがOAuthにおける認可の考え方です。

「OpenID Connect」は認証？

OpenID Connect（OIDC）は、ユーザー認証に利用されるプロトコルです。

OpenID Foundationは、OpenID Connectについて、OAuth 2.0を基盤として、

利用者の身元を確認できる認証プロトコル

と説明しています。

OpenID Connect Core 1.0でも、

OAuth 2.0の上に構築されたIdentity Layer

として、クライアントがエンドユーザーの身元を検証できる仕組みを定めています。

簡単に整理すると、

OAuth 2.0＝「何へのアクセスを許可するか」

OpenID Connect＝「利用者が誰なのか確認する」

です。

OAuthだけを「ログイン」に使うと何が問題？

OAuth公式サイトは、OAuthを単独でログイン認証として利用することについて、一般的な誤りであり、セキュリティ上の問題につながる可能性があると注意しています。

OAuthは基本的に、

「アクセスを許可するための仕組み」

だからです。

利用者が誰なのかを確認する必要がある場合には、OpenID Connectなど認証を目的として設計された仕組みを利用します。

「アクセストークン」と認可の関係

OAuthでは、

アクセストークン（Access Token）

が利用されます。

アクセストークンは、クライアントアプリが保護されたリソースへアクセスする際に利用する資格情報です。

たとえば、

「このアプリは写真を読み取る権限を持っている」

といった認可結果に基づき、APIアクセスに利用されます。

アクセストークンは、基本的に「ユーザーが誰なのかをアプリへ知らせるためのIDカード」と同一ではありません。

「IDトークン」とは？

OpenID Connectでは、

ID Token

というトークンが定義されています。

IDトークンには、認証されたエンドユーザーに関する情報を表すClaimsなどが含まれます。

OpenID Connect Coreは、クライアントが利用者の身元を確認するための仕組みとしてIDトークンを定義しています。

したがって大まかには、

アクセストークン＝API・リソースへアクセスする認可と関係

IDトークン＝ユーザー認証の結果をクライアントへ伝えるために利用

と整理できます。

ただし実装では、各トークンの仕様・Audience・Scope等を正しく確認して扱う必要があります。

「Scope」とは？

OAuthでよく登場する言葉に、

Scope（スコープ）

があります。

スコープは、アプリへ要求・許可するアクセス範囲を表すために利用されます。

たとえば、

• プロフィールを読む
• 写真を読む
• 予定表を読む
• データを書き込む

といった権限範囲です。

このようにOAuthでは、

「何を許可するか」

が中心になります。

そのためOAuthは認可の仕組みだと理解できます。

「ログインできるのに403エラー」になるのは認可？

可能性があります。

HTTPでは、状況によって、

403 Forbidden

が、サーバーはリクエストを理解しているものの、アクセスを拒否している状態を表すために使われます。

利用者の認証自体は完了していても、対象リソースを利用する権限がないためアクセスできないケースがあります。

ただしWebサービスごとにエラー処理は異なるため、403が表示されたからといって原因が必ず認可だけとは限りません。

認証に成功したのに認可に失敗する具体例

会社の社員Aさんが、正しいパスワードと多要素認証を使って社内システムへログインしたとします。

この時点では、

認証成功

です。

その後、社員Aさんが、管理者専用の、

「全社員のアカウント削除」

機能へアクセスしようとします。

一般社員にはその権限がないため、

認可失敗

となります。

本人であることは確認できています。

しかし、その操作をする資格がないということです。

「認証・認可」で迷ったときの3秒判定

こんな場合	答え
パスワードを確認する	認証
パスキーで本人確認する	認証
多要素認証を行う	認証
一般社員に閲覧だけ許可する	認可
管理者だけ削除を許可する	認可
OAuth 2.0でAPIアクセスを許可する	認可
OpenID Connectでユーザーの身元を確認する	認証
誰かは分かるが権限がない	認証済み・認可されていない

最も簡単に覚えるなら、

認証＝「誰？」

認可＝「何をしていい？」

です。

「認証」を使った例文

• パスワードを使って利用者を認証する。
• 多要素認証を有効にする。
• 指紋認証で本人確認を行う。
• 利用者の認証に失敗した。
• OpenID Connectを利用してユーザーを認証する。

「認可」を使った例文

• 管理者にデータ削除を認可する。
• ユーザーの役割に応じてアクセスを認可する。
• APIへのアクセスが認可された。
• 権限のない操作は認可しない。
• OAuth 2.0を利用して限定的なアクセスを認可する。

具体例で比較：ネットバンキング

ネットバンキングへアクセスし、ID・パスワードや追加の認証手段を使って、

「この利用者は口座の所有者本人である」

と確認する処理は認証です。

その後、

「この利用者は自分の口座残高を見られる」

「他人の口座は見られない」

と制限するのが認可です。

具体例で比較：WordPressなどの管理画面

Webサイト管理システムで、ユーザー名・パスワードを使って本人確認するのは認証です。

ログイン後、

• 購読者
• 投稿者
• 編集者
• 管理者

などの役割によって実行できる操作を変えるのは、認可・アクセス制御に当たります。

同じシステムへログインできても、ユーザーごとに利用できる機能が違うのはこのためです。

具体例で比較：クラウドサービスと外部アプリ

外部アプリが、あなたのクラウドサービスにあるデータの一部を利用したいとします。

まずクラウドサービス側で利用者本人を確認する処理は認証に関係します。

その後、

「この外部アプリに写真の読み取りだけを許可しますか？」

とアクセス範囲を決める処理が認可です。

OAuth 2.0は、このような限定的なアクセス権を扱うための代表的な仕組みです。

よくある間違い1：「認証」と「認可」は同じ意味だと思う

違います。

認証は本人性の確認、認可はアクセス権限の判断です。

よくある間違い2：「ログインできたら何でもアクセスできる」と思う

認証に成功しても、利用できるリソース・操作は認可によって制限される場合があります。

よくある間違い3：「パスワードを確認するのは認可」と思う

パスワードを使って本人であることを確認する処理は、基本的に認証です。

よくある間違い4：「管理者権限を確認するのは認証」と思う

本人が管理者ロールを持ち、対象操作を許可されているか判断する部分は認可・アクセス制御に関係します。

よくある間違い5：「OAuthはログイン認証の規格」と思う

OAuth 2.0は基本的に認可フレームワークです。

ユーザー認証を扱う場合には、OAuth 2.0を基盤としたOpenID Connectなどが利用されます。

よくある間違い6：「認証が強ければ認可設定は不要」と思う

非常に強力な多要素認証を導入しても、その利用者へ必要以上の権限を与えていれば、認可・アクセス制御上の問題は残ります。

認証の強さと権限管理は別々に考える必要があります。

よくある間違い7：「認可されなかった＝本人確認に失敗した」と思う

本人確認には成功していても、その機能を利用する権限がないため拒否される場合があります。

つまり、

認証成功＋認可失敗

という状態は普通に存在します。

「認証」と「認可」に関するよくある質問

Q1. 「認証」と「認可」の一番簡単な違いは？

認証は「あなたが誰か」を確認し、認可は「あなたが何をしてよいか」を判断します。

Q2. ログインは認証ですか？

一般的なログイン処理では、ユーザー本人を確認する認証が中心的な役割を持ちます。

ただしログイン処理全体にはセッション管理など、認証以外の処理が含まれる場合があります。

Q3. パスワードは認証と認可のどちら？

パスワードは主に本人確認、つまり認証に利用されます。

Q4. 管理者権限は認証ですか？

管理者本人であることの確認は認証です。

その人に管理機能の利用を許可することは認可です。

Q5. 認証に成功してもアクセスできないことはありますか？

はい。

本人確認が成功しても、対象リソースへの権限がなければ認可されず、アクセスを拒否されることがあります。

Q6. OAuthは認証ですか？

OAuth 2.0は基本的に認可のためのフレームワークです。

OAuth公式サイトも、OAuth単独をログイン認証として扱うのは適切ではないと説明しています。

Q7. OpenID Connectは何のための仕組みですか？

OpenID ConnectはOAuth 2.0を基盤にした認証プロトコルで、クライアントがエンドユーザーの身元を確認できるようにします。

Q8. アクセストークンとIDトークンは同じですか？

同じではありません。

アクセストークンは保護されたAPI・リソースへのアクセスに利用され、IDトークンはOpenID Connectで認証されたユーザーに関する情報をクライアントへ伝えるために利用されます。

Q9. 認証と認可はどちらが重要ですか？

どちらも重要です。

認証が弱ければ他人になりすまされる可能性があります。

認可が不適切なら、正規ユーザーでも本来アクセスできない情報を閲覧・変更できる可能性があります。

Q10. 迷ったときの簡単な見分け方は？

「この人は本当に本人？」 → 認証

「この人にこの操作を許してよい？」 → 認可

と考えてください。

まとめ

「認証」と「認可」はIT・Webサービスで頻繁に使われる言葉ですが、役割は明確に異なります。

認証	認可
Authentication	Authorization
AuthN	AuthZ
「あなたは誰？」を確認	「何をしてよい？」を判断
パスワード・パスキー等	権限・ロール・ポリシー等
本人確認	アクセス制御
OpenID Connect等と関係	OAuth 2.0、RBAC等と関係

最も簡単な覚え方は、

認証＝「誰なのかを確かめる」

認可＝「何を許可するか決める」

です。

たとえば会社のシステムでは、正しいパスワードやパスキーによって社員Aさん本人だと確認するのが認証です。

その後、社員Aさんに、

• 自分の情報は閲覧可能
• 一部のデータは編集可能
• 管理者専用機能は利用不可

といった権限を適用するのが認可です。

したがって、

「ログインできた＝すべての操作を許可された」

ということではありません。

また、Web技術を理解するときには、

OAuth 2.0＝主に認可

OpenID Connect＝認証

と整理すると、両者の役割を理解しやすくなります。

認証と認可は、どちらか一方だけで十分なものではありません。

「正しい利用者であることを確認する認証」

と、

「その利用者へ必要な範囲だけ権限を与える認可」

を適切に組み合わせることが、安全なWebサービスや情報システムを作る基本となります。

参考リンク・出典

• NIST CSRC Glossary「Authentication」
  ― Authenticationを、ユーザー・プロセス・デバイス等の身元を確認し、システムリソースへのアクセスに先立って本人性を検証するプロセスとして定義
• NIST CSRC Glossary「Authorization」
  ― Authorizationを、ユーザー・プログラム・プロセス等へアクセス権限を付与すること、またはシステムオブジェクトへのアクセスを許可・拒否する判断として定義
• Microsoft Learn「Authentication vs. authorization」
  ― Authenticationを本人性の証明、Authorizationを認証済みの主体へデータ・機能へのアクセス権限を与えることとして比較
• Microsoft Learn「Authorization basics」
  ― Authorizationによってアクセス可能な機能・リソース・データや実行可能な操作を決定することを解説
• IETF RFC 6749「The OAuth 2.0 Authorization Framework」
  ― OAuth 2.0を、第三者アプリケーションへHTTPサービスへの限定的アクセスを与えるAuthorization Frameworkとして規定
• OAuth「Frequently Asked Questions about OAuth 2.0」
  ― OAuthはAuthorization Protocolであり、OAuth単独をユーザー認証・ログインに利用することは適切ではないこと、認証にはOpenID Connectを利用することを説明
• OpenID Foundation「OpenID Connect Core 1.0」
  ― OpenID ConnectをOAuth 2.0上のIdentity Layerとして定義し、クライアントがエンドユーザーの身元を検証する認証機能とID Tokenを規定
• OpenID Foundation「How OpenID Connect Works」
  ― OpenID Connectがユーザーの身元を確認するAuthentication Protocolであることと、OAuth 2.0との関係を解説

※本記事ではIT・Web分野における「認証（Authentication）」と「認可（Authorization）」の違いを解説しています。行政法などで使われる「認可」とは意味・文脈が異なります。

※「認証の後に認可」という流れは一般的ですが、匿名ユーザーへ公開情報の閲覧を許可する場合など、すべての認可判断が個人認証を必須とするわけではありません。

※OAuth 2.0は認可フレームワークです。OAuthを利用するすべてのサービスがOpenID Connectを利用しているわけではなく、実際のログイン・認証方式はサービスごとに確認する必要があります。

※アクセストークン・IDトークンは目的・対象・検証方法が異なります。アプリケーション開発では各仕様に従って正しく取り扱う必要があります。

※認証・認可技術やセキュリティ上の推奨事項は更新される場合があります。実際のシステム設計では、NIST、IETF、OpenID Foundation、利用するクラウドサービス等の最新仕様・ガイドラインを確認してください。