コンテンツにスキップ

認証アーティファクトの運搬

はじめに

本サイトにつきまして、【IT技術の知見】はじめに - 俺の技術ノート をご認識のほど宜しくお願いいたします。


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