Authorization Bearer ヘッダを用いた認証 API の実装

認証 API を実装する上で、トークンのやりとりを行う必要がある。トークンの発行はレスポンスに含めれば良いのでどうとでもなるが、トークンの受け取りは色々方法がある。

リクエストボディに含めるやり方はどうとでもなるので、ヘッダを使用する方法を調べてみる。（ダウンロードさせる API も用意したいので、トークンをリクエストボディに含めて送信させる形式も必要）

ヘッダを使用する方法については以下の記事にまとまっている。

ヘッダを送信する場合は以下のことを守る。

仕様ではスコープについても記述があるが、今回は触れない。

サーバーからのレスポンスをいくつかの場合ごとに例示する。

正しいトークンが送信された場合は、通常のレスポンスを返せば良いので、ここでは認証エラーが起こった場合のレスポンスを挙げる。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

認証が必要なリソースに、認証ヘッダなしでアクセスした場合は WWW-Authenticate ヘッダに realm パラメータをつけて返す。 realm パラメータの値はリソースについての適切な説明を返す。当然のことだが、トークンの類推が容易になるような情報を返してはならない。

認証ヘッダ自体がない場合には、下記に示す error パラメータはつけない。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
  error="invalid_token",
  error_description="The access token expired"

送信されたトークンが正しくなかった場合は WWW-Authenticate ヘッダに error パラメータをつけて返す。 error パラメータの値は invalid_token を返す。

オプションで、詳細な説明を error_description で返すことができる。当然のことだが、トークンの類推が容易になるような情報を返してはならない。

RFC 6750 には以下のような推奨事項が書かれている。

トークンは localStorage に保存して、対象の API サーバー以外にはトークンを送信しないようにする。特に、 XSS 脆弱性には気をつけて実装する必要がある。

また、トークンを URL に含めて返さなければならない場面では、トークンの有効期限をできる限り短くしておく。さらに、このトークンが有効な API を限定しておく。

Authorization: Bearer ヘッダを使用した認証を実装する上で必要なことについてまとめた。

特に難しいことはなく、レスポンスヘッダを適切に返せば良い。トークン自体の運用については別な記事でまとめる。

げっとシステムログ