HTTP上で認証を行う場合,
- セッションによる認証
- リクエストボディにトークンを含める認証
- 独自ヘッダにトークンを含める認証
- Authorizationヘッダを用いた認証(Basic, Digest, Bearer)
- JWT認証
など, 様々な方法がある.
この記事ではAuthorizationヘッダを用いた認証のうち, 特にBearer認証についてまとめている.
認証と認可
そもそも認証や認可とは何を指す言葉なのか.
認証 ... ある個人を特定すること
認可 ... 行動やリソースの許可をすること
よくあるWebサービスの場合, 認証を行った時点でそのユーザが使用できる機能が決まるため, 認可もされているということになる.
Bearer認証
Bearer認証は, トークンを利用した認証・認可に使用されることを想定しており, OAuth 2.0の仕様の一部として定義されているが, その仕様内でHTTPでも使用しても良いと記述されている.
bearerは「担い手」や「使い」といった意味を持つ.
詳細は, 『RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage』を参照.
HTTPのAuthorizationヘッダにスキームとして指定でき, Authorization: Bearer <token> のようにして指定する.
トークンの形式はtoken68の形式で指定することが定められている.
Authorizationヘッダ
Authorizationヘッダの仕様に関しては, 『RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication』を参照.
Authorizationヘッダに指定できるスキームには, BasicやDigest, Bearer等が存在し, これらのスキームはIANAによって管理されている.
token68
token68は１文字以上の半角英数字, - (ハイフン), . (ドット), _ (アンダーバー), ~ (チルダ), + (プラス), / (スラッシュ)から構成された文字列を指す.
文字列の末尾に任意個の = (イコール)が挿入されていても良い.
リクエストとレスポンス
まずクライアントから Authorization: Bearer <token> を含めたリクエストが投げられる.
それを受け取ったサーバは WWW-Authenticate: Bearer realm="XXXX" 形式, 又は WWW-Authenticate: Bearer error="XXXX" 形式のヘッダを含めたレスポンスを返す.
成功パターン
特に返したいパラメータが無い場合は realm を空にして返す.
WWW-Authenticate: Bearer realm=""
失敗パターン
リクエストにAuthorizationヘッダが含まれていないケース(401 Unauthorized)
WWW-Authenticate: Bearer realm="token_required"
リクエストパラメータが不正なケース(400 Bad Request)
WWW-Authenticate: Bearer error="invalid_request"
トークンが失効, 破損しているケース(401 Unauthorized)
WWW-Authenticate: Bearer error="invalid_token"
トークンのスコープが不十分なケース(403 Forbidden)
WWW-Authenticate: Bearer error="insufficient_scope"
トークンはどこに保持するのか
クライアント側はlocalStorageかsessionStorage, サーバ側はDBに保存することになる.
トークンに有効期限は設けるのか
トークンが漏れてしまうと第三者がそのトークンを使ってあらゆる操作ができてしまうため, 有効期限は設けておくべき.