Autho0ではこれまで、クッキーの
samesite属性にはtrue、false、strict、laxのオプションがありました。属性が手動で設定されていない場合、Auth0はデフォルト値のfalseを使用していました。2020年2月より、Google Chrome v80によるクッキーの取り扱いが変わりました。Auth0はこれを受けて、クッキーの処理方法を以下のように変更しました。samesite属性が設定されていないクッキーは、laxに設定されます。sameSite=noneのクッキーは、セキュリティ保護が必要です。そうしないとブラウザーのcookie jarに保存できません。
クッキーベースの認証
通常、シングルページアプリ（React・Vue・AngularJS + Nodeなど）、ネイティブモバイルアプリ（iOS・Androidなど）とWeb API（Node・Ruby・ASP.NETやその混合）には、トークンベースの認証が最も適しています。サーバー側のWebアプリケーションでは、伝統的にクッキーベースの認証が使用されてきました。 Webプラットフォームはそれぞれ、クッキーベースの認証を異なる方法で実装していますが、結局のところ、認証済みのユーザーを表すのに（サーバー上のセッションに紐づけられた）何らかのクッキーを設定しています。それぞれの要求についてそのクッキーが送信され、何らかのストア（1台のサーバーであればメモリ内、サーバーファームであれば何らかの永続ストレージ）からセッションが非直列化されます。Auth0ではほとんどのプラットフォーム用にSDKを提供して、対応する認証サブシステム（nodeのpassport、.NETやJavaのIPrincipalなど）と結び付けます。 認証を要求するアプリケーションの構築では、それぞれの要求時にユーザーが認証済みかを判断するために、セッションやクッキーを使用することができます。クッキーはステートフルとステートレスから選ぶことができます。ステートフルクッキー
ステートフルクッキーには、セッション情報を保管するデータベースレコードへのポインターが含まれます。 利点- 保管するセッション情報の量に制限がありません。
- データベースからレコードを削除するだけで、ユーザーのセッションを簡単にクリアできます。
- セッションデータをデータベースに保管する必要があります（ただし、ほとんどのWebアプリケーションはすでにこれを行っています）。
- ユーザーがHTTP要求を行うたびにセッションを読み取る（時には書き込む）のにデータベースを呼び出す必要があるため、遅延が増加します。
- ユーザーの数が多く、データベースに対する読み取りや書き込みが多くなる場合には、規模の調整が困難なこともあります。
ステートレスクッキー
ステートレスクッキーは自己完結型で、クライアントにある必要なセッション情報（認証済みのユーザーではユーザーID）がすべて含まれています。外部からの改ざんを防ぐために、ステートレスクッキーは必ず暗号化（少なくとも署名）されなければなりません。 利点- 手軽に実装できます。特別なバックエンドは必要ありません。
- データベースを呼び出す必要がないため、遅延が低減されます。
- 規模の調整が簡単です。
- クッキーにはサイズ制限（ほとんどのブラウザーで最大4KB）があるため、保管されるセッション情報を制約する必要があります。セッション情報を複数のクッキーに分割することもできますが、推奨されません。
- データベースに削除可能なレコードがないため、セッションの取り消しが困難になります。セッションを強制的にクリアする別の方法を用意する必要があります。
- 複数のWebサーバーを使用している場合には、クッキーの暗号化と復号化や署名に使用する鍵がすべてのサーバーになくてはなりません。