私はRESTジャージーWebサービスを持っています。
私の質問はこの質問の答えについてです。確認してください。
その答えの中で、それはそれについて言及しました。
「次に、このトークンのハッシュとリクエストの特定の特性を送信して、リクエストを認証します。たとえば、sha1（Token + Timestamp + Request URL + Request Body）。サーバーは、クライアントがプレーンテキストでトークンを送信しなくてもこれを検証できます。リクエストごとに」
サーバーが「クライアントがリクエストごとにプレーンテキストでトークンを送信する必要なしに」検証する方法を誰かが説明できますか？クライアントは毎回サーバーにトークンを送信する必要がありますか？
もう1つの質問は、サーバーがこのトークンのハッシュ（タイムスタンプやユーザーIDなどを含む）を受信すると、トークンが格納されているルックテーブルやDBがなくても、サーバーはこのトークンからユーザーをどのように識別するのでしょうか。
最初の質問の場合：クライアントはハッシュバージョンのトークンを送信でき、サーバーはハッシュ値をクライアントから受信した値と比較します。
2番目の質問については、トークンとユーザーの間のマッピングをメモリ内、ディスク上、または適切と思われる場所に保持できます。
これは、サーバー側にのみ存在する秘密鍵を使用して認証トークンの一部の暗号化/復号化を使用するアプローチの過度に単純化された例です。AUTHORIZATION_TOKENはクライアントに送信でき、その後のリクエストで送信されます。
1）ログインするには、ユーザーはユーザーID、パスワード、セッションID、タイムスタンプを送信します
。2）検証が成功すると、サーバーはTOKEN = encode（secretkey、userid + sessionid + time_stamp）を生成します。
3）サーバーはAUTHORIZED_TOKEN = TOKEN + userid + sessionid +タイムスタンプをクライアントに送信します
4）クライアントはセッション中のすべてのリクエストでこのトークンを送信します
5）サーバーはAUTHORIZED_TOKENのTOKEN部分を復号化し、復号化されたuserid、sessionid、timestampをTOKENから解凍して比較しますそして、それをAUTHORIZED_TOKENのプレーンテキストの対応物と比較します。
6）不等式がある場合、サーバーはログインページにリダイレクトします。
7）重要な情報はプレーンテキストで送信されません。
8）シークレットキーはサーバー側にのみ存在します
9）トークンにはユーザーIDが含まれているため、ディスクまたはメモリへのユーザーマッピングは必要ありません