ログインテクノロジーの選択
プロジェクトのログイン認証方法を見直したところ、以前の方法は合理的ではないことが判明したため、ログイン方法を整理するために学習することを思いつき、主に説明するこの記事を思いつきました。実際のコードはインターネット上の既存の記事を参照することができます 1.
JWT+redis (プロジェクトでは当初この方法を使用しましたが、後に無理があることが判明しました)
2. token+redis
3. JWT
4.セッション
JWT
定義と構造
JWT—Json Web トークンはトークン トークンであり、中央のJWT 構造の
ドットで区切られた 3 つの部分で構成される String 文字列です。header ヘッダー:トークンのタイプと使用される署名アルゴリズムが含まれますペイロード ロードはロードする場所ですデータ (宣言(ユーザー情報 (ユーザー名、パスワード)およびその他のデータに関するステートメント)を含む)署名 署名 ヘッダーとペイロードは、base64 で暗号化された data であり、ソルト処理されてから 2 回暗号化されます。
JWT ログイン検証プロセス
1. 初めてログインするとき、フロントエンドはバックエンドのログイン インターフェイスを調整し、ユーザー名とパスワードを送信します。 2. バック
エンドはリクエストを受信し、ユーザー名とパスワードを検証し、検証は成功しました。ユーザー情報を含むデータは JWT のペイロードとして使用され、JWTヘッダーが Base64 でコーディングされて個別に結合され、署名されてJWTトークンを形成します。形成された JWT トークンは文字列ですlll.zzz.xxx のように
3. フロントエンドはトークンを取得し、ルーティングページにジャンプします
4. フロントエンドは毎回バックエンドを調整します インターフェースはリクエストヘッダーにトークンを追加する必要があります 5.
バックエンドはトークンがあるかどうかを判断しますリクエスト ヘッダーにトークンが含まれています。トークンがある場合は、トークンを取得してトークンを検証します。検証が成功するとデータが返され、検証が失敗した場合 (例: トークンの有効期限が切れた場合)、401 が返されます。 、リクエストヘッダーにトークンがないため、401 が返されます。
JWT の長所と短所:
1. JWT はステートレスであり、サーバーはログイン ステータス情報を保存する必要がないため、サーバーの負荷が軽減されます。
2. Cookie に依存する必要がないため、CSRF 攻撃を回避できます。
1. JWT はログアウトやログインなどのシナリオでは引き続き有効であり、サーバーはトークンをアクティブに無効にすることができません
。
上記のシナリオに基づくと、JWT は次の場合に適しています。
- 有効期間が短い
- 一度だけ使いたい
- クロスドメイン ログイン (一貫性のないプロトコル、ドメイン名、ポート番号) (これは、プロジェクトで JWT を使用する理由の 1 つでもあり、Springboot と Flask の 2 つのバックエンドがあります)
たとえば、ユーザーが登録した後、アカウントをアクティブ化するために電子メールを送信します。通常、電子メールにはリンクが必要です。このリンクには次の特性が必要です: ユーザーを識別できること、リンクは時間に敏感であること(通常は数時間以内にのみアクティブ化が許可されます)、他の考えられるアカウントを一度だけアクティブ化するために改ざんすることはできません。このシナリオは jwt の使用に適しています。
JWT の欠点について、解決策はありますか?
1. ログアウト後もトークンは有効です
** トークンを Redis に保存するか、ブラックリスト メカニズムを確立します **
ここでは Redis メモリ データベースが適切な選択です。トークンを無効にする必要がある場合は、redis からトークンを直接削除してください。ただし、これでは、トークンを使用してリクエストを送信するたびに DB にトークンの存在を問い合わせるステップが発生し、JWT のステートレス原則に違反します。
2. 更新の問題
redis 上で jwt ごとに有効期限を設定し、アクセスするたびに jwt の有効期限を更新しますが、jwt が redis 上に存在しない場合は期限切れとみなされます。しかし、これはJWT のステートレス原則にも違反します。
要約すると、JWT はセキュリティ要件の低い一部の小規模なプロジェクトにのみ適しており、JWT+redis を使用すると、実際には JWT 設計の本来の意図に違反します。
Redis+トークン
1 ユーザー ID をキーとして使用し、生成されたトークンを値として使用し、それを Redis にキャッシュして有効期限を設定します。 2 生成されたトークンをキーとして使用し、ユーザー情報を値として使用し、
Redis にキャッシュして有効期限を設定します。フロントエンドの場合
、フロントエンドはトークンをヘッダーに置き、他のインターフェイスを呼び出すときにそれを運びます。
ログアウトする場合は、redis から上記 2 つの情報を削除するだけです
セッション + クッキー
セッションを使用する理由
HTTP プロトコルのステートレスな性質は、クライアントの各 HTTP リクエストが独立しており、連続する複数のリクエスト間に直接の関係がなく、サーバーが各 HTTP リクエストのステータスを積極的に保持しないことを意味します。
セッションログイン検証ワークフロー
多くの場合、特定のユーザーを実装するために SessionID を使用しますが、SessionID は通常 Redis に保存されます。例えば：
- ユーザーはシステムに正常にログインし、SessionID を含む Cookie をクライアントに返します。
- ユーザーがバックエンドへのリクエストを開始すると、SessionID が取得されるため、バックエンドはユーザーの ID ステータスを認識します。
マルチサービス ノードでのセッション Cookie
1. 各サーバーによって保存されたユーザー セッションは一貫しています
2. 保存には単一のデータ ノードを使用します
Cookie がない場合でもセッションは使用できますか?
1. SessionID を Cookie に保存するのが一般的ですが、リクエストの URL https://harry.com/?Session_id=xx に配置することもできます。