コンテンツにスキップ

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

はじめに

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


適するユースケース

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

  • 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


02. 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ヘッダーがいいらしい。


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

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