現在、RESTful API 用に OAuth 2.0 アーキテクチャを実装しています。
リクエストごとに、すべてのクライアントが承認済みリクエストを作成できるように、HTTP ヘッダーに承認ベアラー トークンを設定します。
Authorization: Bearer sdflksd3r4823vkn95-03850432
有効期限が切れるまで API でトークンを受け入れるのが一般的であることを理解しています。しかし、ユーザーがトークンを取り消したい場合は、リクエストごとにトークンのステータスを確認する方法を採用する必要があります。
だから私はすべてのHTTPリクエストをチェックするためにDbに行くことを考えていました. パフォーマンス上の理由から、これはうまくスケーリングできないと感じています。
それで、 Redisのようなソリューションが、アクセス トークン ステータスの非常に高速な単一読み取りに適しているかどうか疑問に思っていました。
トークンに HMAC を使用するポイントは、サーバーが外部データ ストア (Redis、MySQL など) を呼び出さずにトークンをすばやく検証できるようにすることです。これには、共有状態がないため、複数のサーバーに適切にスケールアウトできるという追加の利点があります (トークンを検証するためのすべての情報は、トークン自体であり、HMAC のキーです)。
取り消されたトークンのブラックリストを作成する場合は、おそらく Redis のようなもので問題ありません (ただし、トークンの検証ごとにリモート呼び出しを行わない場合よりも遅くなります)。Redis インスタンスと API サーバーの間のレイテンシーが低く、適切にセットアップすると、リクエストごとに 10 ミリ秒未満になるはずです。
おまけ:さらに高速化するもう 1 つのオプションは、Bloom フィルターを使用して、拒否された API 要求のキャッシュを処理することです。そうすれば、Bloom フィルターがリクエスト トークンに失効の可能性があるというフラグを立てた場合にのみ、Redis にアクセスできます。これはキャッシュの別のレイヤーであるため、トークンが拒否されたときにブルーム フィルターの状態を更新する必要があることに注意してください。
私は自分のために似たようなものを作っています。
トークンの構文と暗号化については、 JWTを使用することをお勧めします。これはそのための優れた標準です。
redis を使用してトークン/ユーザー ID のペアを保存しても問題ありません。有効期限の値を設定できるからです。
また、ブルームフィルターを途中で挿入しましたが、sehrope の提案とは逆の方法で作成しました。ログイン時にすべてのトークンをブルームフィルターで保存しているため、トークンが存在しない場合は間違いなく無効です。それ以外はおそらく正しいですが、確実にRedisをチェックする必要があります。しかし今、問題があります。認証システムをスケールアップしたい場合は、認証サーバー間にステートフル ロード バランサーが必要です。私見、ブルーム フィルターを使用してブラックリストを作成するのは正しくありません: ブルーム フィルターでブラックリストに登録すると、取り消されたトークンと間違ったトークンが除外され、アイテムがブラックリストに登録されていない場合、ブルーム フィルターは false を返します (そして、redis バックエンドで確認する必要があります)。認証); それ以外の場合、要素が存在する (ブラックリストに登録されている) 場合は、redis で確認する必要があります。なぜなら、ブルーム フィルターの true 応答は誤検知になる可能性があるためです。