認証と認可の違い&手法についてまとめる
この記事の目的
Webアプリケーションサービスでよく使用される認証&認可について、それぞれの役割を確認し主な手法についても紹介する。
認証と認可の違い
認証とは
認証（authentication：AuthN）は、通信相手が誰（何）であるかを確認すること。
ログイン機能が代表的な認証機能である。
認証情報は大きく3要素に分けられる。
認証の3要素
- 知識情報
パスワードや暗証番号などユーザー本人だけが知っている情報 - 所持情報
スマートフォンやセキュリティキー、ICカードなどユーザー本人だけが物理的に所持しているものに含まれる情報 - 生体情報
指紋や顔、虹彩などのユーザー本人の生物学的な情報
認可とは
認可（authorization：AuthZ）は、通信相手へ特定の権限を与えること。
認証と同時に認可も受け付けることも多い。
例えばX（旧：twitter）では、認証（ログイン）するとツイートの投稿権限も与えられる（認可）。
認証・認可の手法
HTTPで定義されている認証
-
ベーシック認証（Basic Authentication）
ユーザーがユーザー名とパスワードをサーバーに送信して認証を行う最も基本的な方法。
ユーザー名とパスワードはBase64でエンコード（64進数に変換すること）され、暗号化されずに送信されブラウザに保存される。
IDとパスワードを毎回送信するため、盗聴により容易にIDとパスワードが盗まれてしまう（Base64のデコードも容易である）、ログアウト機能がなく再度認証する必要がないため、なりすましのリスクが高いなどセキュリティレベルが低い。HTTPS通信にするとインターネット通信を暗号化するため、Basic認証の暗号化されないという欠点は補われるが、毎回認証情報を送信している、という欠点は解消されない。※MDNでもベーシック認証は安全ではないと記載されている。
-
ダイジェスト認証（Digest Authentication）
Basic認証の平文で「ユーザーID」と「パスワード」を送信してしまう欠点を改善した認証方式で、ユーザー名とパスワードをハッシュ化（ハッシュ関数と呼ばれる特殊な計算方法を用いて、元のデータを不規則な文字列に変換する処理方法）して送信する。
中間者攻撃（攻撃者の制御下にあるノードに通信を中継させることで、通信内容を盗聴したり改ざんしたりする攻撃）に弱い、用意されているハッシュ関数も解析可能などの脆弱性がある。
HTTPSを使えばベーシック認証で良いので、HTTPしか使えない環境で使用するとよい。
フォーム認証（Form Authentication）
HTMLで作られたフォーム画面からIDとパスワードを送信する認証方式のこと。
IDとパスワードは平文で送信されるので、SSL（HTTPS）を使用して暗号化通信するのが一般的。
ベーシック認証やダイジェスト認証と違いHTTPの仕様にはない認証方式なので、アプリ側で実装をする必要がある。
HTMLのフォーム画面より入力されたIDとパスワードをサーバーに送信すると、サーバはIDとパスワードが正しいかを検証する。正しければセッション管理を開始し、ブラウザにセッションIDを返却する。
ブラウザは返却されたセッションIDが有効な期間、ログインしたWebページを閲覧することが出来る仕組み。
パスワードは漏洩しても大きな問題にならないように、データベースにハッシュ化した値で保存しておく。
ログアウト機能やシングルサインオン機能（1つのIDとパスワードを入力して、複数のWebサービスやアプリケーションにログインできる仕組みのこと）を実装することができる。
セッション認証（Session Based Authentication）
サーバーがユーザーがログイン成功した際に一意のセッションIDを発行し、そのIDを使用してユーザーを識別する認証方式のこと。通常はCookieまたはURLパラメーターにセッションIDが保存される。
ユーザーはこのセッションIDをブラウザ上でクッキーとして保存して、サーバー側へリクエストを送る。
サーバーはリクエストされたセッションIDを確認して、対応するユーザーの情報を取得する。
取得した情報をもとに、そのユーザーがアクセス可能or不可能なリソースに対するリクエストをおこなっているのか判別して、その結果を返す。
セッションはサーバー側で管理されているため、セキュリティを高めるためにSSLを使用することが推奨されている。
フォーム認証とセッション認証はどちらもセッション管理を利用するが、フォーム認証はユーザーが認証情報を提供する手段を指し、セッション認証は認証されたユーザーを識別するためにセッションを使用する方法を指す。
トークン認証（Token Based Authentication）
トークンを使用する認証方式のこと。ユーザーが認証に成功すると、サーバーはトークンを発行し（このトークンは、セッションIDとは異なり、ユーザー情報と紐付けされない）そのトークンを次のリクエストで送信することでユーザーを識別します。トークンはサーバー側で生成され、通常は有効期限を持つ。
セッション認証はステートフル（状況によってレスポンスが変わる）な通信であり、トークン認証はステートレス（状況によらず、あるリクエストに対するレスポンスが必ず同じ結果になる）な通信である。
また、セッション認証はサーバーにセッションIDとユーザ情報を持たせておく必要があるので、ユーザー数の増加したときにサーバー負荷が大きくなる。
一方で、トークン認証はそうした情報を持たせないめ、ユーザが増加した時のサーバ負荷が少ない。
JWT認証（JWT Authentication）
JWT（JSON Web Token）はトークン認証の一種で、JSON形式で情報をエンコードし、署名を使用して認証と情報の安全性を確保する認証方式のこと。JWTには有効期限が含まれており、署名が検証されるため、改ざんが困難である。
通常のトークン認証では、トークンの正当性を確認するためにサーバへの問い合わせが必要。一方JWTでは公開鍵（通信を暗号化するときに使うキー）を利用してクライアント側でトークンの正当性を確認できるという特徴がある。
JWTのトークンには有効期限が含まれており、有効期限内であれば、サーバーにトークンを確認するためのネットワーク接続がなくても、そのトークンが有効であることが保証される。一方有効期限内であると、トークンを取り消すこともできないため、トークンが漏洩した場合や不正利用された場合、そのトークンを無効にすることが難しい場合がある。
また通常のトークンがそれ自体では全く意味を持たないケースがほとんどであるのに対して、JWTはそれ自体が情報を持つトークンとなっている。このためJWTの内部に個人情報などを含めることは推奨されない。
OAuth
OAuthは複数のWebサービスを連携して動作させるために使われる認可の仕組み。通常、Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要があるが、OAuthを利用することで、IDやパスワードを入力することなく、アプリケーション間の連動ができる。
たとえば、ある写真管理アプリに写真を投稿したときに、同時にユーザーアカウントでTwitterに「写真管理アプリに写真を投稿しました」というメッセージといっしょに、写真を投稿したページのURLをツイートするような仕組みのこと。
一見通常のアプリのふりをしてOAuth認証を受けることで、マルウェア（コンピュータウィルスや、コンピュータに入力したIDやパスワードをのぞき見るようなプログラム）をダウンロードするページへのリンクをTwitterでつぶやいたり、SNSサービスの掲示板に書き込むような悪質なアプリ提供者もいる。むやみやたらに連携認可をしないことが求められる。
参考文献
Discussion