以前の 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 に保存できません。
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の暗号化/復号や署名に必要なキーを持っていることを確認する必要があります。