SpringのデフォルトのOAuth JWT実装がJWTベリファイアを公開するのはなぜですか？以下のように（client_credentialsの助成金を使って）

Question

SpringのデフォルトOAuth JWTフローは次のとおりです。

1. 起動認証サーバ（AS）
2. 打ち上げリソースサーバ（RS）
   • 起動時にRSはtokenKeyを要求
3. ASは、RS256（SHA256withRSA）
を使用して公開鍵を返す基本認証を使用して GET /oauth/token_keyを呼び出すことにより、
4. は、いくつかの時間後に、クライアントがclient_credentialsが
5. ASがJWS signature
6. クライアントを含むJWT accessToken返しRS
7. RSの用途へのベアラトークンとしてJWTを送信許可使用GET /oauth/tokenを呼び出すことによってaccessTokenを要求しますJWT accessTokenがASから来たことを確認するために起動時にASから受け取ったtokenKeyこれは私が混乱するところです...

これは安全ですか？共有秘密鍵ではなく、公開証明書を使用するのはなぜですか？ハッカーが公開鍵を簡単に入手して、有効なJWT accessTokenに署名することはできませんでしたか？公開鍵証明書とJWT署名の併用は、送信者が実際に認証サーバーであり、攻撃者ではないことを確認するためにどのように連携しますか？

洞察が役立ちます。

Answer 1

公開鍵暗号とデジタル署名の性質にいくつかの研究は、これをgleans：

デジタル署名を非対称暗号化を実装します。デジタル署名は、受信者に、そのメッセージが主張された送信者によって送信されたと信じる理由を与える。手書きの署名と同様に、それらは偽造するのが難しい。署名者（この場合はAS）は、秘密鍵を秘密に保ち、秘密鍵を使用して署名を作成します。一部の否認防止スキームは、デジタル署名のタイムスタンプを提供するため、秘密鍵が公開されていても署名は有効です。

デジタル署名方式は、典型的には3つのアルゴリズム

1）の可能な秘密鍵のセットからランダムに一様に秘密鍵を選択key generation algorithmから成ります。このアルゴリズムは、秘密鍵および対応する公開鍵を出力する。

2）メッセージと秘密鍵

3）を使用して署名を作成signing algorithmsignature verifying algorithmすなわち、メッセージ、公開鍵と署名、受け入れ又は真正メッセージの主張を拒否のいずれかを与えられました。

この場合（RS256）、署名はSHA256withRSAを使用して作成されました.RSAは暗号化アルゴリズムとして使用されず、むしろデータの起点または真正性を検証するために使用されます。署名は秘密鍵を使用して生成されました。公開鍵は、署名を検証するために使用されるリソースサーバに渡されます。このシナリオでは、たとえ攻撃者が公開鍵を持っていても、署名付きのなりすましメッセージを作成したり内容を変更することはできません。