ここでは oauth については説明しません。まず jwt を理解したいと思います。
検証とログイン保持という 2 つの概念がよくわかりません
現在、Android クライアントと iOS クライアントにキーシークレットを与えており、サーバーもこのシークレットを使用しています
その後、タイムスタンプやノンスなどのクライアントのパラメータが、私が指定したキーと照合され、複数のパラメータが 1 つのパラメータ記号に暗号化されます。
は一緒にサーバーに渡され、サーバーは最初のいくつかのパラメーターとサーバーのパスワードを暗号化し、最後にクライアントによって送信された最後のパラメーターの符号
と等しいかどうかを判断します。しかし、今私が行った上記の検証は、このリクエストのクライアントが私のサーバーの秘密鍵を知っていること、つまりこのリクエストが私のサーバーによって許可されていることを証明しているだけだと思います
しかし、ユーザーがログインしたかどうかはまだわからないので、ユーザーがログインインターフェイスを要求して正常にログインした場合、セッションを Redis に保存するようにクライアントに依頼しました。 1 か月後、token=sessionid を返し、それをクライアントに保存して、次回私がそれを持ってきて、redis でこのセッションを見つけることができれば、彼がログインしていることが証明されます
。また、オンラインで誰かがこれはカスタム JWT だと言いましたよね?
私がやったことと jwt の最大の違いは何なのかわかりません
たとえば、私のメソッドはセッション ID に依存してユーザーのログイン ステータスを決定し、サーバーはセッションを保存します。
Jwt しばらく情報を読んだところ、クライアントにトークンを発行した後、サーバーはトークンを保存していないようです。その後、クライアントのパラメーターが到着した後、それは単なる最初のステップであるようです。私自身の方法(複数のパラメータとキーを暗号化した後に署名するのは等しいですか?) しかし、多くの情報は、これが事実である場合、ログインをすでに証明できると言っているようです、私の方法は冗長であり、ログを記録するかどうかを決定するためにセッションを使用しています。
で?
https://jwt.io/
JWT の特徴の 1 つは、ステートレスであり、ログインの概念がないことです。
本来、いわゆるログインというのは人間が理解できる概念でしかなく、サーバーにはこの概念がありません。ログインとは何ですか?許可がある場合のみ(ログイン後にのみアクセスできるコンテンツ)。
jwt はサーバー側にトークンを保存する必要がありません。トークンには発行者、ユーザー、署名、その他の情報が含まれており、ログインを証明するのに十分であり、改ざんされていないためです。一度改ざんされると、署名を検証することができないためです。 sessionidに関しては異なります。セッションは主に、サーバー側に他のデータを保存するために使用されます。これらのデータは機密性が高く、JWT に置くのは不便です。もちろん、セッションはストレージの一種にすぎません。Redis や他の種類のストレージ システムに保存することもできます。実際、Cookie をトークンと考えることもできます (これは間違いですが、この方がよりよく理解できるでしょう)。セッションは値の 1 つにすぎず、それ以上のものではありません。