コンテンツにスキップ

認証情報の運搬＠認証情報による分類

はじめに

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


適するユースケース

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

  • CSR
  • SSR


セッションデータで認証情報を運搬する場合

セッションベース認証の場合、セッションデータを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を作成し、セッションデータに書き込む。

# セッションデータ
{ 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


セッションデータで認証情報を運搬する場合

セッションベース認証の場合は、セッションデータを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キーをクエリストリングに割り当てる。