セッションとトークンベースの認証
認証のために実装する方が安全かどうかを知りたいのですが、なぜですか？セッションベースの認証ORトークンベースの認証
セッションは他の目的にも使用できることは知っていますが、今は認証にしか興味がありません。
トークンを使用する場合（メモリにさえない場合）、サーバー側に何も保存されないのは本当ですか？はいの場合、同じ秘密を使用して署名されたトークンが期限切れのトークンに対してどのように識別されますか？
セッションベース認証
セッションベースの認証では、サーバーはすべての負荷の高いサーバー側を実行します。大まかに言えば、クライアントはその資格情報で認証し、session_id（Cookieに保存可能）を受け取り、これを後続のすべての発信要求に添付します。したがって、これは資格情報のセットに相当するため、「トークン」と見なすことができます。
ただし、このsession_id-Stringについては何も凝っていません。これは単なる識別子であり、サーバーは他のすべてを実行します。ステートフルです。識別子をユーザーアカウントに関連付けます（メモリ内またはデータベース内など）。このセッションを特定の操作または特定の期間に制限または制限することができ、セキュリティ上の懸念がある場合は無効にし、さらに重要なことに、このすべてをオンザフライで実行および変更できます。
さらに、ウェブサイト上のすべての動きをユーザーに記録できます。考えられる不利な点は、拡張性が悪いこと（特に複数のサーバーファームで）と大量のメモリ使用量です。
トークンベースの認証
トークンベースの認証では、サーバー側で永続化されるセッションはありません（ステートレス）。最初の手順は同じです。資格情報はトークンに対して交換され、トークンはその後のすべての要求に添付されます（Cookieに保存することもできます）。
ただし、メモリ使用量、簡単な拡張性、および柔軟性（トークンは別のクライアントと交換可能）を削減するために、必要なすべての情報を含む文字列（トークン）が発行されます。サーバ。
トークンを使用/作成する方法はいくつかあります。
ハッシュメカニズムの使用HMAC-SHA1
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)--idとexpiry_idは、結果のハッシュが添付された平文で送信されます（kはサーバーのみが知っています）
トークンを対称的に暗号化するAESを使用
token = AES(user_id|expiry_date, x)--xはen- /復号化キーを表します
非対称に暗号化するRSAを使用
token = RSA(user_id|expiry_date, private key)
アプリケーションで
生産システムは通常、これらの2つのアーキタイプよりも複雑です。たとえばAmazonは、Webサイトで両方のメカニズムを使用しています。また、ハイブリッドを使用して、2で説明するトークンを発行し、ユーザートラッキングまたは失効の可能性のためにユーザーセッションをそれに関連付けても、従来のトークンのクライアントの柔軟性を維持できます。また、OAuth 2.0は、短命で特定のベアラトークンと長寿命の更新トークンを使用して、ベアラトークンを取得します。
出典：