コンテンツにスキップ

認証アーティファクトの運搬＠認証アーティファクトによる分類

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. 運搬方法の一覧

マイクロサービスアーキテクチャの文脈では、各認証アーティファクトにさまざまな運搬媒体があります。

セッションID、アクセストークンであるJWTトークンやOpaqueトークン、APIキーはHTTP/1.1リクエストの Cookie ヘッダーや Authorization ヘッダーで運搬できます。

HTTP/2では、ヘッダー名は小文字にする必要があります。

HTTP/1.1 HTTP/2 セッションID JWTトークン Opaqueトークン APIキー
Cookie ヘッダー cookie ヘッダー ✔︎ ✔︎ ✔︎
Authorization ヘッダー authorization ヘッダー 無 ✔︎ ✔︎ ✔︎
カスタムヘッダー カスタムヘッダー ✔︎
クエリパラメーター :path ヘッダー


適するユースケース

フロントエンドアプリケーションが以下の場合に適する。

  • CSR
  • SSR


セッションIDを運搬する場合

セッションベース認証の場合、セッションIDを Cookie ヘッダーで運搬する。

(1)

セッションIDを Cookie ヘッダーに割り当て、リクエストを送信する。

(2)

最初、ユーザー作成の段階で、クライアントが資格情報をサーバーに送信する。サーバーは、資格情報をDBに保管する。

POST https://example.com/users
---
# ボディ
{"email_address": "foo@gmail.com", "password": "foo"}
(3)

次回の認証時に、再びユーザーが資格情報を送信する。

POST https://example.com/foo-form
---
# ボディ
{"email_address": "foo@gmail.com", "password": "foo"}
(4)

サーバーは、DBの資格情報を照合し、ログインを許可する。サーバーは、セッションIDを作成し、セッションIDに書き込む。

# セッションID
{ sessionid: ***** }
(5)

レスポンスの Set-Cookie ヘッダーにセッションIDを割り当て、クライアントに送信する。Set-Cookie ヘッダーにより、クライアントは Cookie ヘッダーを設定しなければいけなくなる。

200 OK
---
Set-Cookie: sessionid=<セッションID>
(6)

サーバーは、セッションIDとユーザーIDを紐付けてサーバー内に保管する。

加えて次回のログイン時、クライアントは、リクエストのCookieヘッダーにセッションIDを割り当て、クライアントに送信する。

サーバーは、保管したセッションIDに紐付くユーザーIDから、ユーザーを特定し、ログインを許可する。

これにより、改めて資格情報を送信せずに、素早くログインできるようになる。

POST https://example.com/foo-form
---
cookie: sessionid=<セッションID>
(7)

認証解除時、サーバーでセッションIDを削除する。


アクセストークンを運搬する場合

トークンベース認証の場合、アクセストークンを Cookie ヘッダーで運搬する。

CSRFトークンと組み合わせるとさらに良くなる。

なお、APIではリクエストの送受信時に Cookie ヘッダーよりも Authorization ヘッダーのほうが扱いやすいため、Authorization ヘッダーでアクセストークンを運搬することになる。

また、スマホアプリも Cookie ヘッダーより Authorization ヘッダーがいいらしい。

JWT


03. Authorization ヘッダーによる運搬

適するユースケース

フロントエンドアプリケーションが以下の場合に適する。

  • CSR


セッションIDを運搬する場合

セッションベース認証の場合は、セッションIDを Authorization ヘッダーで運搬することはない。


アクセストークンを運搬する場合

トークンベース認証の場合、アクセストークンを Authorization ヘッダーで運搬する。

POST https://example.com/foo
---
authorization: Bearer <ヘッダーJSONエンコード値>.<ペイロードJSONエンコード値>.<署名JSONエンコード値>

なお不便ではあるが、Authorization ヘッダーは Cookie ヘッダーとは異なり、ローカルマシンに保管できない。

その代わり、ブラウザの設定によって、ブラウザのWebストレージで保管できる (Chromeでは、LocalStorageあるいはSessionStorage) 。

なお、APIではリクエストの送受信時に Cookie ヘッダーよりも Authorization ヘッダーのほうが扱いやすいため、Authorization ヘッダーでアクセストークンを運搬することになる。

また、スマホアプリも Cookie ヘッダーより Authorization ヘッダーがいいらしい。


04. クエリストリングによる運搬

例えば、Google APIではAPIキーをクエリストリングに割り当てる。