4

これは実際には、プロセス全体を理解するために多くの個別の質問に分解されます。

  1. 私が理解していることから、JWT は互いに別々に base64 にエンコードされた 3 つの JSON オブジェクトです。次に、Base64 文字列がピリオドで区切られます。これは純粋に「より短いメッセージ」の目的で行われますか?

  2. これらには、ヘッダー、「ペイロード」、および署名が含まれます。ヘッダーとペイロードは、傍受した人なら誰でも 100% 読み取ることができます。これらは、JSON にデコードして読み取ることができる単なる base64 文字列です。

  3. 次に、MAGIC: サーバーは、デコードできない SIGNATURE を受信します。署名は、実際にはヘッダー、ペイロード、および秘密鍵のハッシュです。したがって、サーバーはヘッダー、ペイロード、および ITS OWN 秘密鍵を受け取り、ハッシュを作成します。このハッシュがメッセージに付属の署名と一致する場合、メッセージは信頼されています。署名が一致しない場合、メッセージは無効です。

このすべての問題？ここの 2 つの別々のキーはどこにありますか? メッセージの暗号化に使用されたキーと、メッセージの復号化に使用されたキーは同じようです。これが私の質問の根源です。他に何も答えない場合は、これを手伝ってください。

それ以外は、プロセスを正しく理解しているのだろうか？また、「公開鍵に同意」し、ここで公開鍵と秘密鍵の「混合物」を取引する標準はどこにありますか? 私が見るのは、エンコード/デコードに使用されているのと同じキーだけです。しかし、合意はいつ行われたのですか？これを .NET と Auth0 のコンテキストで表示すると、全体的に q.

誰かが後でこのqを見ることに興味があるなら、私が見た/読んだ/使用したランダムなもの:

JWT の概要: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token

公開鍵/非対称暗号: https://youtu.be/3QnD2c4Xovk

ハッシング: http://www.webopedia.com/TERM/H/hashing.html

Base64: http://en.wikipedia.org/wiki/Base64

4

2 に答える 2

3

まず、JSON Object Signing and Encryption standard (JOSE) は base64url エンコーディングを使用し、単純な base64 エンコーディングではなく、わずかに異なります。

  1. JWT ヘッダーとペイロードは JSON オブジェクトですが、署名はそうではありません。base64url でエンコードされたバイナリ BLOB です。

  2. JWT全体は、それを傍受する人なら誰でも利用できます.3つの部分すべて

  3. 送信者と受信者が同じ共有鍵を使用する対称鍵アルゴリズムについて説明しています。これは JWTS の 1 つのオプションにすぎません。もう 1 つのオプションは、署名/検証/暗号化/復号化に公開/秘密キーのペアを使用することです。

すべての暗号と同様に、鍵の合意は帯域外で行われる必要があります。

于 2015-05-25T19:03:48.613 に答える