認証と認可の違い。Authentication と Authorization を基礎から整理する

「認証」と「認可」は、日本語でも英語でも音や見た目がよく似ています。英語ではAuthentication(認証)とAuthorization(認可)で、どちらも「Auth」で始まるため、会話の中で略して「Auth」と言われると、どちらを指しているのか分からなくなることもあります。しかし、この二つは役割がまったく別物です。混同すると、設計の穴になり、現実のセキュリティ事故につながります。

ごく短く言えば、認証は「あなたは誰か」を確かめること、認可は「あなたは何をしてよいか」を決めることです。ログイン画面でIDとパスワードを入力して本人だと確認するのが認証、ログインした後に「この人は一般利用者だから他人の請求書は見られない」と制御するのが認可です。順番としては、まず認証で相手を特定し、その特定された相手に対して認可で権限を割り当てる、という流れになります。

この記事では、これから開発やシステム管理を学ぶ方に向けて、認証と認可の違いを原理から噛み砕きます。両者を混同したときに起きる典型的な事故(アクセス制御の不備)、IDトークンとアクセストークンの役割の違い、そしてOAuth2.0とOpenIDConnectがそれぞれ認可と認証のどちらを担うのかという関係まで、具体例を交えて整理します。

まず結論。認証と認可の違いを一枚で#

言葉の定義を先に並べておきます。略語のAuthN(認証)とAuthZ(認可)は、エンジニアの会話や設計書でよく使われます。NとZは、AuthenticationとAuthorizationの綴りの中から、区別しやすい文字を取ったものです。

重要なのは、この二つが別々の処理として独立して存在するという点です。認証に成功したからといって、すべての操作が自動的に許されるわけではありません。「本人であること」と「その操作をしてよいこと」は別の判断であり、システムはその両方を、それぞれの場面でチェックしなければなりません。ここを一体だと思い込むことが、後述するアクセス制御の不備の根っこにあります。

認証(AuthN)とは。「あなたは誰か」を確かめる#

認証は、目の前の相手が「名乗っている通りの本人か」を確かめる手続きです。建物の入口で身分証を見せて本人だと確認してもらう場面に近いものです。代表的な方法は、本人だけが知っている/持っている/その人自身である、という3種類の要素に分けられます。

• 知識(知っているもの): パスワード、PIN
• 所持(持っているもの): スマホの認証アプリ、セキュリティキー
• 生体(その人自身): 指紋、顔

パスワードという「知識」一つだけに頼ると、それが漏れた瞬間になりすましを許します。そこで、異なる種類の要素を2つ以上組み合わせる多要素認証(MFA)が推奨されます。認証を強くすること自体が大きなテーマなので、方式の比較や導入の進め方は

認可(AuthZ)とは。「何をしてよいか」を決める#

認可は、認証で特定された相手に対して、「この人にはどの操作・どのデータを許すか」を決める手続きです。本人確認が済んでいることが前提で、その上に権限の層が乗ります。

身近な例で考えます。あるECサイトに正しくログインできたとします。これは認証の成功です。しかし、ログインできたからといって、他人の注文履歴を見たり、商品の価格を書き換えたり、全ユーザーの個人情報をダウンロードしたりしてよいわけではありません。一般利用者には「自分の注文を見る」「自分の住所を変更する」程度しか許されず、価格変更や全ユーザー情報の閲覧は管理者だけに許されます。この「誰に何を許すか」の制御が認可です。

混同が招く事故。アクセス制御の不備#

認証と認可の混同が最も危険な形で現れるのが、「認証は実装したが、認可チェックを忘れた」というパターンです。これはOWASP(Webアプリのセキュリティに関する代表的なコミュニティ)が挙げる**Broken Access Control(アクセス制御の不備)**そのものです。OWASP Top 10:2025では、このアクセス制御の不備が最も重大なリスクとしてA01(第1位)に位置づけられています。

OWASP Top10:2025のA01「Broken Access Control」は「アクセス制御は、利用者が意図された権限の外で行動できないようにポリシーを強制するものだ」と定義し、2025年版でも第1位を維持しています。POST/PUT/DELETEに対するアクセス制御の欠落や、URLのID書き換えで他人のデータにアクセスできてしまう問題などが代表例として挙げられています。

典型的なやられ方を一つ示します。あるWebアプリで、注文詳細ページのURLが次のような形だったとします。

https://example.com/orders/1024

ここで利用者がログイン済み(認証済み)であることだけを確認し、「この注文1024番が、いまログインしている本人のものか」を確かめていないと、URLの数字を1025や1026に変えるだけで、他人の注文が見えてしまいます。これは認証は通っているのに認可の判断が抜けている状態で、IDOR(Insecure Direct Object References、安全でない直接オブジェクト参照)とも呼ばれます。サーバー側で毎回「この資源は、このリクエストを送ってきた本人がアクセスしてよいものか」を確認していないことが原因です。

APIの設計でこの抜けは特に起きやすく、PUTやDELETEといった更新系のエンドポイントで認可チェックが漏れると影響が大きくなります。API特有の注意点は

最小権限とアクセス制御モデル(RBAC/ABAC)#

認可を設計するときの基本方針が最小権限の原則です。これは「必要な人に、必要な範囲だけ、必要な期間だけ権限を与える」という考え方で、OWASPも「公開資源を除き、原則すべて拒否(deny by default)」を勧めています。まず全部禁止しておき、必要なものだけ明示的に許可する、という向きで設計するとミスが減ります。逆に「まず全部許可して、危ないものを後から塞ぐ」と、塞ぎ忘れがそのまま穴になります。

「誰に何を許すか」を管理する代表的な方式が、RBACとABACです。

RBACは、利用者一人ひとりに直接権限を付けるのではなく、「管理者」「編集者」「閲覧者」といった役割を作り、役割に権限を束ねて、利用者には役割を割り当てる方式です。人事異動があっても役割を付け替えるだけで済むため、管理がしやすいのが利点です。

ABACは、利用者の所属・端末・場所・時間帯・対象データの機密度といった「属性」を組み合わせて、その都度アクセス可否を判断する方式です。NISTのガイドラインSP800-162では、ABACを「主体・対象・要求された操作、場合によっては環境条件に関連する属性を、ポリシーに照らして評価することで認可を決める方式」と定義しています。

NIST SP 800-162「Guide to Attribute Based Access Control (ABAC) Definition and Considerations」は、属性ベースのアクセス制御(ABAC)の定義と考え方を示した一次文書です。RBACで使うロールも、見方を変えれば属性の一種であり、ABACはより一般的な枠組みとして位置づけられます。

入門段階では、まずRBACで「役割ごとに何を許すか」を整理し、必要に応じてABAC的な条件(場所や端末の状態など)を足していく、という順序で考えると無理がありません。なお、場所や端末の状態をアクセス判断に組み込む発想は、アクセスのたびに文脈を検証するゼロトラストの考え方とも地続きです。

トークンの役割の違い。IDトークンとアクセストークン#

最近のWebサービスやアプリでは、ログインのたびにパスワードをやり取りするのではなく、「トークン」と呼ばれる証明書のようなデータを使って認証・認可を扱うのが一般的です。ここで認証と認可の混同がまた起きやすいので、二つの代表的なトークンの役割を分けて理解しておきます。

IDトークンは、OpenIDConnect(後述)で発行される、認証の結果を表すトークンです。「誰が・いつ・どのように認証されたか」という情報(クレーム)を含みます。受け取ったアプリは、署名や発行者(iss)・宛先(aud)・有効期限(exp)などをきちんと検証したうえで、「確かにこの利用者がログインした」と判断します。受け取っただけで信用してよいわけではなく、検証はOpenIDConnectの仕様でも必須とされています。IDトークンは、APIへのアクセス権を表すものではありません。検証済みの本人確認の証明書だと考えてください。

アクセストークンは、APIを呼び出すときに「この呼び出しを許可してよい」という認可の情報を運ぶトークンです。たとえば「このカレンダーの予定を読む権限」だけを持ったアクセストークンを使えば、アプリはその範囲のAPIだけを呼べます。アクセストークンは「誰か」を厳密に伝えるためのものではなく、「何をしてよいか」を伝えるためのものです。

この二つを取り違えると問題が起きます。たとえば、APIの認可判断にIDトークンをそのまま流用したり、アクセストークンの中身から本人確認を済ませたつもりになったりするのは、設計上の誤りです。IDトークンは認証の結果、アクセストークンは認可の手段、という役割分担を崩さないことが大切です。

OAuth2.0は認可、OpenIDConnectは認証#

トークンの背景にある二つの標準が、OAuth2.0とOpenIDConnectです。名前が並んで出てくるため同じものと思われがちですが、担当する役割が違います。

OAuth2.0は、その正式名称が「The OAuth 2.0 Authorization Framework」、つまり認可の枠組みです。IETFのRFC6749として標準化されています。OAuth2.0が解決するのは、「あるアプリに、利用者の資源への限定的なアクセスを安全に委ねる」という問題です。たとえば、写真印刷サービスに、自分のクラウドストレージの写真フォルダだけを読む権限を渡す、といった場面です。ここで渡しているのは「何をしてよいか(写真を読む権限)」であって、「あなたは誰か」を確かめること自体は、OAuth2.0の主目的ではありません。

RFC 6749「The OAuth 2.0 Authorization Framework」は、サードパーティのアプリケーションがHTTPサービスへの限定的なアクセスを取得できるようにする認可の枠組みを定義した一次仕様です。名称が示す通り、これは認可(Authorization)の標準です。

一方のOpenIDConnect(OIDC)は、このOAuth2.0の上に乗せた「認証のための層(アイデンティティレイヤー)」です。OpenIDFoundationが管理しており、OAuth2.0の仕組みを使って「利用者が誰であるか」を確認できるようにします。OpenIDConnectは、UserInfoエンドポイントや標準化されたクレームなど複数の仕組みを足しますが、その中心になるのが前節のIDトークンです。これにより、アプリは標準化された形で「確かに本人がログインした」という認証の結果を受け取れます。

OpenID Foundationの解説によれば、OpenID Connectは「OAuth 2.0フレームワークに基づく相互運用可能な認証プロトコル」であり、OAuth2.0が認可を担うのに対し、OpenID Connectはそれをベースにアイデンティティ(本人確認=認証)のサービスを提供します。

整理すると、次のようになります。OAuth2.0だけでは「何をしてよいか(認可)」は扱えても、「あなたは誰か(認証)」を標準的な形では扱えません。そこにOpenIDConnectを足すことで、認証まで含めて扱えるようになります。実際の「ログインで他社サービスのアカウントを使う(ソーシャルログイン)」の多くは、このOpenIDConnectの上に成り立っています。よくある誤解として「OAuthでログインしている」という言い方をしますが、厳密には認証部分を担っているのはOpenIDConnect、というのが正確な理解です。

よくある質問#

まとめ#

認証と認可は、似た言葉でありながら、役割の異なる二つの判断です。認証は「あなたは誰か」を確かめ、認可は「あなたは何をしてよいか」を決めます。この二つを別物として意識することが、アクセス制御の不備という最も多い事故を防ぐ第一歩になります。実装では、ログインできたかどうかだけで安心せず、操作のたびに「この本人にこの操作を許してよいか」をサーバー側で確かめる習慣を付けてください。そして、トークンや標準(OAuth2.0とOpenIDConnect)を扱うときも、いま自分が認証を扱っているのか認可を扱っているのかを常に問い直すことが、堅牢な設計につながります。