私はいくつかの開発のために一連のRESTfulサービスを実装しており、そのうちの1つは認証サービスです。
この認証サービスは、次の2種類のIDを認証します。
- アプリケーション。AppKeyベースの認証。これにより、クライアントは残りのサービスにアクセスするためにキーを登録する必要があります。
- ユーザー。よく知られている資格情報（ユーザー+パスワード）ベースのユーザー認証。これにより、人間とマシンはクライアントアプリケーションを介してこれらのRESTfulサービスを操作できます。
これらのRESTfulサービスはステートレスです。
クライアントアプリケーションが認証サービスに対して認証する場合、または人間またはマシンが資格情報を使用してIDとして認証する場合、両方の操作でそれぞれAppTokenとUserTokenが生成されます。
これらのトークンはソルトハッシュであるため、RESTfulインフラストラクチャへの後続のリクエストは、AppKeyとクレデンシャルを共有せずに認証されます。
完全にステートレスなアプローチの観点から、これらのトークンはサービスレイヤーのどこにも保存するのではなく、ある種のクライアント側の状態で保存する必要があります（fe、WebクライアントはHTTP Cookieを使用して保存します）。これが私の現在の実装が現在どのように機能しているかです。
これらのトークンを使用して各リクエストを再認証し、サービスレイヤーがクライアントからのトークンを受信できるようにするため、クライアントからのトークンを比較し、それが有効なトークンであるかどうかを確認して、サービスレイヤーでトークンを再生成し、クライアントが所有するものは高すぎるため、トークンかどうかを確認するために、有効期限と所有者（トークンが作成されたアプリケーションまたはユーザー）の両方を持つサービスレイヤーAppTokenとUserTokenを実装しましたクライアントからの送信はトークンストアに存在します。
クライアントはどのようにインタラクティブに認証を解除しますか？ クライアント側のセキュリティ状態を削除するだけです。Webクライアントの場合、認証Cookieを削除し、ページを更新するだけで、クライアントは認証Cookieを検出せず、ユーザーはログインページにリダイレクトされます。
RESTfulサービスの観点からは、これはステートレスな認証解除です。クライアントは、サービス層の疑似認証状態を持つトリックを認識していません。これは、サービス実装の詳細（パフォーマンスの最適化）にすぎません。
ステートレスサービスの長所をリストするつもりはありません。これは、このアプローチが進むべき道であると確信しているためですが、問題が見つかりました。ステートレス認証/非認証は、クライアントがセッションを閉じることをサーバーに通知しないことを意味します。 、したがって、セキュリティストアは多くの役に立たないレコードで終わります。
サービスクライアントが限られた時間（fe、1時間、3時間、1日...）のクライアントである場合、これは大きな問題ではありませんが、ユーザーが永久に認証される必要がある場合（8か月、1年）はどうなりますか）？。期限切れのトークンとはどのように区別しますか？
この状況を解決するためのいくつかのアプローチがあります。
サービスレイヤーはリクエストを受信するたびにトークンの有効期限を更新するため、自動化されたプロセスにより、トークンの任意の有効期限（fe 24時間）を定義して有効期限が切れたトークンが削除される場合があります。
アーキテクチャのステートレスな性質を損ない、クライアントが認証されたくないことをサービスレイヤーに通知できるようにすることで、サービスは関連付けられたトークンをクライアントセッションにドロップできます（ただし、クライアントがWebクライアントを閉じるとどうなりますか？ユーザートークンを削除する必要があることをサービスに積極的に通知することはありません...したがって...ゾンビトークンはまだ存在するため、自動化されたプロセスで削除する必要がありますが...ゾンビトークンとは何ですか？このアプローチは好きではありません）。
完全にステートレスな認証、ストアなし、リクエストごとの認証。
これが質問です！1.、2。、または3.でなくても、提案されているアプローチは何ですか。その理由は何ですか。
この長い読書に感謝します-私は正直に言って、質問の結論は誰にとっても非常に役立つだろうと信じています-！