Skip to main content
Cookie は、ウェブサーバーがブラウザーに送信するデータ文字列です。ブラウザーが後でウェブサーバーに request を送信する際には、その request と一緒に同じ文字列もウェブサーバーに送信します。
以前の Auth0 では、samesite Cookie 属性のオプションは true、false、strict、lax でした。属性を手動で設定しなかった場合、Auth0 はデフォルト値として false を使用していました。 2020 年 2 月から、Google Chrome v80 では Cookie の処理方法が変更されました。これに対応するため、Auth0 でも Cookie の処理方法に次の変更を実装しました。
  • samesite 属性が設定されていない Cookie は、lax に設定されます。
  • sameSite=none が設定された Cookie はセキュアである必要があります。そうでない場合、ブラウザーの Cookie jar に保存できません。
これらの変更は、セキュリティを向上させ、CSRF 攻撃の緩和に役立てることを目的としています。
ウェブサイトでは通常、ユーザーがページ間を移動しても認識できるように Cookie を使用し、毎回ログインし直さなくて済むようにしています。また、ユーザーが入力した情報を記憶するためにも Cookie を使用します。たとえば、EC サイトでは、ショッピングカートに入れた商品を記憶するために Cookie を使用します。 ユーザーは、ブラウザーの設定を変更することで、Cookie を受け入れるかどうかを選択できます。 通常、シングルページアプリ (React、Vue、AngularJS + Node など) 、Native モバイルアプリ (iOS や Android など) 、そして Web API (Node、Ruby、ASP.NET、またはそれらを組み合わせて構築されたもの) は、トークン ベースの認証のメリットを最も受けやすい種類です。一方、従来型のサーバーサイド Web アプリケーションでは、従来から Cookie ベースの認証が使われてきました。 Cookie ベースの認証は Web プラットフォームごとに実装方法が異なりますが、最終的にはどの場合も、認証済みユーザーを表す何らかの Cookie (サーバー上のセッションにひも付いたもの) を設定することになります。リクエストのたびにその Cookie が送信され、セッションはどこかのストアからデシリアライズされます (単一サーバーならメモリ内、サーバーファームなら永続ストレージなど) 。また、対応する認証サブシステム (Node の passport、.NET や Java の IPrincipal など) と連携する SDK を、ほとんどのプラットフォーム向けに提供しています。 認証が必要なアプリケーションを構築する場合は、リクエストが行われるたびにユーザーが認証済みかどうかを判断するために、セッションと Cookie を使用できます。そのためには、ステートフル Cookie とステートレス Cookie のいずれかを選択します。

​
ステートフルなCookie

ステートフルなCookieには、セッション情報を保存しているデータベースのレコードを参照するポインタが含まれます。 長所:
  • 保存できるセッション情報の量に制限がありません。
  • ユーザーのセッションを簡単に削除できます。データベースからレコードを削除するだけです。
短所:
  • セッションデータを保存するにはデータベースが必要です (ただし、ほとんどのWeb アプリケーションではすでに使用されています) 。
  • ユーザーがHTTP リクエストを送るたびに、セッションを読み取るためのデータベースアクセス (場合によっては書き込みも) が必要になるため、遅延が増えます。
  • ユーザー数が多くなり、それに伴ってデータベースの読み書きも増えると、スケーリングが難しくなることがあります。

​
ステートレスCookie

ステートレスCookieは自己完結型で、必要なセッション情報 (認証済みユーザーの場合はuser ID) をすべて含み、クライアント側に保存されます。外部からの改ざんを防ぐため、ステートレスCookieは暗号化するか、少なくとも署名する必要があります。 長所:
  • 容易に実装でき、特別なバックエンドも必要ありません。
  • データベースを呼び出す必要がないため、レイテンシを低減できます。
  • スケールしやすいです。
短所:
  • Cookieにはサイズ制限があるため (ほとんどのブラウザーで最大4KB) 、保存できるセッション情報を制限しなければなりません。セッション情報を複数のCookieに分割することもできますが、お勧めしません。
  • 削除できるデータベース上の記録がないため、セッションを取り消しにくくなります。セッションを強制的にクリアするには、別の方法を検討する必要があります。
  • 複数のWebサーバーを使用する場合は、すべてのサーバーがCookieの暗号化/復号や署名に必要なキーを持っていることを確認する必要があります。

​
詳細はこちら