6

認証サーバーでJSONWebトークン（JWT）をサポートすることを検討しているため、最新のドラフトは08であるJSON Web暗号化（JWE）仕様を読んでいます。

定義されている非対称暗号化方式を使用して、対称鍵（コンテンツマスター鍵）は受信者の公開鍵を使用して暗号化されます。これは、受信者だけがそれを復号化でき、トークンが受信者向けであることを確認できるようにするために意味があります。

通常、トークンの出所を証明するものも表示されると思います。たとえば、公開鍵を使用して検証できる発行者の秘密鍵を使用して作成された署名などです。ただし、署名は、コンテンツマスターキーまたは受信者の公開キーのいずれかから派生しているように見え、発行者の秘密キーについては言及されていません。

これがないと、予想されたトークンの形式がわかっている限り、受信者の公開鍵を持っている人（つまり誰でも）が有効なトークンを生成できるように思えます。信頼できる認証サーバーだけではありません。

私は暗号化の専門家ではないので（それからはほど遠い）、ここで何かが欠けていると確信しています。受信者は、非対称に暗号化されたトークンが信頼できる発行者からのものであることをどのように確認しますか？

JSON Web Signatures（JWS）仕様では、発行者の秘密鍵を使用し、公開鍵で検証できる署名が定義されていることを考えると、JWEトークンのペイロードをJWSトークンにする必要があるのではないかと思います。

4

1 に答える 1

5

JWTは確かにネストされたペイロードを許可します。実際、仕様には特定の参照があり、cty（content-type）ヘッダーパラメーターを設定しJWTて、ペイロードが実際に別のJWTであることを示すことができます。

したがって、ほとんどの場合、JWEを作成し、秘密鍵で署名されたJWSでラップします。これは、JOSEメーリングリストのこのスレッドからの結論（または少なくとも1つの解決策）でもあるようです。ペイロードサイズの削減に関する別の関連スレッドがあります。一般に、そのメーリングリストは、仕様の背後にいる人々がたむろする場所であるため、おそらく注意を払う価値があります。

于 2013-03-19T15:08:59.977 に答える