認証と認可は、どちらもアプリケーションのセキュリティを守るうえで欠かせない仕組みですが、その役割は異なります。

認証（Authentication）は、利用者が誰なのかを確認する仕組みです。
一方、認可（Authorization）は、その利用者が特定の情報や機能にアクセスしてよいかを判断する仕組みです。

では、ログインさえできれば、アプリケーションは安全なのでしょうか？
例えば、インターネットバンキングにログインした後、他人の口座残高まで自由に閲覧できてしまった場合はどうでしょうか。

ログイン機能が正常に動作していても、適切な認可が行われていなければ、情報漏えいにつながる可能性があります。

前回は、従来のSASTでは認可不備や業務ロジックの脆弱性を見つけにくい理由について解説しました。

なぜ従来のSASTだけでは業務ロジックの脆弱性を見つけにくいのか？ AIが読み解く「文脈と変更」

では、そもそも「認可不備」とは、どのような問題なのでしょうか。

今回は、アプリケーションの安全性を考えるうえで欠かせない「認可」について、「認証」との違いから解説していきます。

認証とは？―「あなたは誰ですか？」

認証とは、利用者が誰なのかを確認する仕組みです。 例えば、オンラインショップへのログインをイメージしてみてください。

ユーザーがIDとパスワードを入力すると、アプリケーションは登録されている情報と照合し、本人であることを確認します。
正しい情報であればログインに成功し、間違っていればログインに失敗します。
他にも、指紋認証、顔認証、多要素認証など本人確認にはさまざまな方法があります。これらは、利用者が本人かどうかを確認するための仕組みです。

つまり、認証が確認するのは、この利用者は誰なのか？ということです。
しかし、本人であることが確認できたからといって、その利用者にすべての操作が許可されるわけではありません。そこで必要になるのが、認可です。

認可とは？―「あなたは何をしてよいですか？」

認可とは、利用者が特定の情報や機能にアクセスする権限を持っているかを確認する仕組みです。
例えば、オンラインショップで次のような注文情報が登録されているとします。

利用者	注文番号	注文金額
Aさん	1001	5,000円
Bさん	1002	30,000円

Aさんがログインすると、自分の注文情報である注文番号: 1001を確認できます。
では、Bさんの注文番号1002についてはどうでしょうか？

Aさんはログインに成功しています。
しかし、Bさんの注文情報を閲覧する権限があるとは限りません。
本来、Aさんに閲覧権限がない場合は、アクセスを拒否する必要があります。ここで働くのが、認可です。

つまり、認可が確認するのは、「この利用者は、この情報にアクセスしてよいのか？」ということです。
なお、認可は情報の閲覧だけではありません。
データの更新や削除、管理機能の実行などについても、適切な権限の確認が必要です。

認証と認可は何が違う？

ここまでの内容を整理してみましょう。

項目	認証（Authentication）	認可（Authorization）
確認すること	利用者が誰なのか	何をして良いのか
具体例	ログイン時の本人確認	自分の注文情報だけを閲覧できる
代表的な問題	なりすまし など	権限の無い情報にアクセス など

ここで押さえておきたいことがあります。
認証に成功したことと、認可されていることは同じではありません。

例えば、企業の社内システムをイメージしてみてください。
一般社員も管理者もどちらも正規のユーザーとしてログインできます。
しかし、すべての社員が人事情報を変更したり、システムの設定を変更できるわけではありません。
ログインできることは、その操作を実行してよいことを意味しないのです。

また、認可の対象はユーザーの役割だけではありません。
同じ一般ユーザーであっても、アクセスできる情報は異なる場合があります。

先ほどのオンラインショップの例では、AさんもBさんも一般ユーザーです。
それでも、お互いの注文情報を自由に閲覧できてはいけません。

このように、誰が・どの情報に・どのような操作を行ってよいかを適切に判断することが重要です。

なぜ、認証だけでは不十分なのか？

前述した、オンラインショップの注文履歴の問題にさかのぼります。
例えば、認可チェックが不十分なアプリケーションでは、次のような判断が行われてしまう可能性があります。

「このユーザーはログインしている。だから注文情報を表示してよい」
一見すると問題なさそうです。

しかし、この判断には重要な確認が抜けています。
「その注文情報は、Aさんが閲覧してよいものなのか？」という確認です。

もしログイン状態だけを確認して、注文情報へのアクセスを許可していたらどうなるでしょうか。
AさんがBさんの注文情報を取得できてしまうかもしれません。

このとき、認証機能には問題がありません。Aさんは正規のユーザーとしてログインしています。
問題なのは、閲覧してよい注文情報かどうかを確認する、認可の仕組みです。

このような問題を防ぐためには、認証だけでなく、対象となる情報や操作に対して適切な認可を行う必要があります。

認可はサーバー側で確認することが重要

Webアプリケーションには、利用者の権限によって表示するボタンやメニューを変更する仕組みがあります。
例えば、一般ユーザーには「管理者向けの設定ボタンを表示しない」といった仕組みです。
しかし、画面上でボタンを非表示にするだけでは、セキュリティ対策として十分ではありません。
利用者が直接APIにリクエストを送る場合もあるためです。

そのため、実際に情報を取得したり、処理を実行したりするサーバー側で、適切な認可チェックを行う必要があります。
重要なのは、利用者がどのような方法でアクセスしても、同じ権限のルールが適用されることです。
また、ログイン時の確認だけでなく、アクセスする情報や実行する操作に応じて、リクエストごとに権限を確認することが重要です。

まとめ：ログインできることと、安全であることは違う

今回は、認証と認可の違いについて解説しました。
認証は、利用者が誰なのかを確認する仕組みです。
認可は、その利用者が特定の情報や機能にアクセスしてよいかを確認する仕組みです。

どちらもアプリケーションのセキュリティを守るうえで重要ですが、役割は異なります。
特に覚えておきたいのは、次の点です。

「ログインしているから安全」とは限らない。

適切な認可が実装されていなければ、正規のユーザーであっても、本来アクセスできない情報を閲覧したり、許可されていない操作を実行したりできてしまう可能性があります。
では、実際のアプリケーションでは、どのような仕組みの不備によって、こうした問題が発生するのでしょうか？

次回は、オンラインショップの注文情報を例に、IDOR（Insecure Direct Object Reference）とBOLA（Broken Object Level Authorization）という脆弱性について解説します。