コンテンツにスキップ

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

はじめに

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


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 キーをクエリストリングに割り当てる。