web-dev-qa-db-ja.com

署名されたJWTの暗号化は、クレームペイロードを保護するために実行可能であると証明されますか？

私はサーバークライアントWebアプリケーションに取り組んでおり、認証スキームとして、base64エンコードされた json web tokens を発行しています。次のトークンを検討してください...

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

そのようにデコード...

{
  "alg": "HS256",        // header
  "typ": "JWT"
},
{
  "sub": "1234567890",   // payload
  "name": "John Doe",
  "admin": true
},
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret') // signature

私の懸念は、このトークンのpayload部分にあります。ここで、定義されたクレームを指定します。 "role": "readonly"。私の懸念は、これらの値が表示され、一度発行されたエンドユーザーによって改ざんされることです。この部分を変更しても、署名チェックは無効になりません。サーバー上にデータを保持して発行されたトークンを再確認/比較したくありません-サーバーを完全にステートレスに保ちたいです。

おそらくトークンに署名し、AES 256を介してそれを暗号化し、これを私の「トークン」として使用すると思いました。フローはそのように要約されます...

  1. base64エンコードされたトークンの生成と署名
  2. aES 256を介したトークンサーバー側の暗号化

  3. 暗号化されたトークンをクライアントに発行する

  4. リクエストを受け取り、暗号化されたトークンを提供

  5. トークンサーバー側の復号化
  6. base64エンコードされたoriginalトークン署名を検証します（クレームが変更されていないことを確認できるようになりました）

私の考えでは、クレーム（ペイロード）は表示されず、この暗号化された値を改ざんしても、明らかにサーバー側で復号化されません。私の質問は-これは実行可能ですか？トークン全体を暗号化するためのWeb上で多くを見つけることができませんでした。 もっと良い方法はありますか？

encryptionauthenticationtokenjwt
9
scniro

2つの質問をしていると思います。

  1. ペイロードを変更すると署名が無効になります：TL; DR：はい
  2. jWTを介して暗号化を追加すると、コンテンツの信頼性が得られます：TL; DR：自分で暗号化しないで、JWEを使用してください！

詳細は次のとおりです。

（1）仕様によると https://www.rfc-editor.org/rfc/rfc7515.txt

署名付きJWT（JWS）の署名は、保護されたヘッダーとペイロードに対して計算されます。

（セクション5.1を参照。メッセージの署名またはMAC計算）

Compute the JWS Signature in the manner defined for the
       particular algorithm being used over the JWS Signing Input
       ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||
       BASE64URL(JWS Payload)).

したがって、ペイロードを変更すると、署名が無効になります。

（2）自分のJWTを暗号化しないでください!! JWT（JWEと呼ばれる）を暗号化する方法を定義する実際の仕様があります： https://www.rfc-editor.org/rfc/rfc7516.txt

JWEは認証された暗号化を使用します。つまり、最初に平文が暗号化され、次に暗号文に対して整合性チェックが生成されます。上記の仕様のセクション5.1から、プレーンテキストがどのように見えるかについての詳細情報を取得できます。

暗号化された形式または署名された形式のいずれかを使用する場合は、JWTのペイロードにアクセスポリシーを安全に格納できます。クライアントまたは他の関係者にポリシーデータの知識を持たせたくない場合は、暗号化を使用できます。誰がそれを読むことができるかは気にせず、誰が値を変更できるかだけを気にする場合は、署名のみを使用してください。

ただし、セキュリティを追加すればするほど、パフォーマンスへの影響が大きくなるので、何が必要かを判断してください。

最後の注意：署名と暗号化キーのキー管理も考慮する必要がある重要な問題になります。結局のところ、キーにアクセスできる人は誰でもJWEを復号化したり、JWSの署名を変更したりできるからです。したがって、実際のキーを格納する場所、それらにアクセスできるユーザー、およびキーの使用方法とメモリ内での保管方法については、適切な安全対策を講じてください。

11
channel