在编写自己的文章之前，我已经经历了多个博客文章和Stackoverflow问题。我有多个查询，没有任何帖子回答它们。
我正在使用KeyCloak Spring Security适配器来保护我的旧版Spring应用程序。我转介到KeyCloak文档 
for EG：访问localhost：8080/about.htm会将我重定向到KeyCloak登录屏幕，并且成功身份验证后，我将能够查看我的页面。我还使用以下代码来阅读令牌中的用户详细信息，
KeycloakPrincipal<KeycloakSecurityContext> kp = (KeycloakPrincipal<KeycloakSecurityContext>) auth.getPrincipal();
IDToken idToken = kp.getKeycloakSecurityContext().getIdToken();
user.setUsername(idToken.getPreferredUsername());
现在当我使用Postman测试此应用程序并修改生成的访问令牌时，显然服务器会出现错误。参考：如何使用Postman进行测试应用程序。 a>
但是，这就是流程：
客户端将请求发送到资源服务器，资源服务器检查令牌 - 如果存在，则客户端进行验证。如果它不存在或无效，则将其重定向到授权服务器（KC）。
我的问题是，
- 谁在验证这个令牌？ Postman流如何丢失错误
如果我摆弄了令牌？
- 我真的需要在我的申请中写一个jwttokenvalidator
每个请求？那不会过分吗？
- 如果我将客户端身份验证者用作签名的JWT，并使用客户端秘密 ，是否需要此验证？我不使用它，因为它引入了延迟。
请协助。
I have gone through multiple blog posts and StackOverflow questions before writing my own. I have multiple queries and none of the posts answer them.
I am using Keycloak Spring Security Adapter to secure my legacy Spring application. I referred to the keycloak documentation here and was able to have OAuth flow running for me. I am using Client Id and Secret as Client Authenticator. 
For eg: Access to localhost:8080/about.htm will redirect me to keycloak login screen and after successful authentication, I will be able to view my page. I am also using the below code to read the user details from the token,
KeycloakPrincipal<KeycloakSecurityContext> kp = (KeycloakPrincipal<KeycloakSecurityContext>) auth.getPrincipal();
IDToken idToken = kp.getKeycloakSecurityContext().getIdToken();
user.setUsername(idToken.getPreferredUsername());
Now when I test this application using postman and modify the generated access token, obviously the server gives an error. Ref : How to test application using postman.
However, this is the flow :
Client sends a request to the resource server, resource server checks for a token - if it exists, the client does the validation. If it doesn’t exist or is invalid, it redirects to the authorization server (KC).
My question is,
- Who is validating this token? How does postman flow throw an error
if I fiddle with the token?
- Do I really need to write a JwtTokenValidator in my application for
each request? Won't that be overkill?
- If I use Client Authenticator as Signed Jwt with client secret, will this validation still be required? I am not using it as it introduces latency.
Please assist.
发布评论
评论（1）
回答＃1 ：
当您在应用程序中使用任何KeyCloak适配器（在您的情况下为KeyCloak的弹簧适配器）时，那就是进行验证并在必要时重定向到登录的人。作为验证的一部分，它检查了KeyCloak发行的令牌的签名。因此，当您摆弄令牌时，签名不匹配，因此会引发错误。
回答＃2
不，您不需要实现jwttokenvalidator。适配器为您提供它，并且只有在具有有效令牌的情况下，请求才能达到您的端点/URL。您可能只需要在验证令牌方面有特殊要求（例如，在令牌中对某些服务检查特定的主张）。否则，您可以安全地使用从
keycloaksecuritycontext中收到的令牌中的索赔。您甚至可以根据您的URL模式进行设置授权，而KeyCloak也将执行它们，并在用户具有必要的角色时允许请求通过（例如此示例）。回答＃3：
该选项仅更改用于将您的应用程序验证到KeyCloak身份验证的方法，并且与应用程序内的用户令牌验证无关。在您当前的设置中，当您的应用程序要与KeyCloak通信（例如，与Auth token交换Auth Code）时，它会使用客户端ID/客户端销售对对KeyCloak进行身份验证（否则，KeyCloak不知道它是您的应用程序，并且将会拒绝请求）。
如果您选择“带有客户秘密的JWT签名的JWT”选项，则您的客户端不能仅使用客户端秘密来验证KeyCloak。它应支持RFC7523规范。因此，与简单的Clien-Secret方法相比，这非常复杂。在您信任客户的环境中（例如，它们都是公司内部开发的知名应用程序，并且您不会支持公共客户加入您的KeyCloak并使用其服务）方法。
Answer to #1:
When you use any Keycloak adapters in your application (in your case the Spring adapter for Keycloak), that's the one who does the validation and redirects to the login if necessary. As part of the validation, it checks the signature of the token issued by Keycloak. So when you fiddle with the token, the signature doesn't match, hence it throws an error.
Answer to #2
No, you shouldn't need to implement a JwtTokenValidator. The adapter does it for you and a request should reach your endpoint/URL only if it has a valid token. You may only need to do that if you have a special requirements about validating the token (e.g. checking specific claim in the token against some service). Otherwise, you can safely use the claims in the token you received from the
KeycloakSecurityContext. You can even setup authorization based on your URL patterns and Keycloak will enforce them too and allow the request to pass if user has necessary roles (like this example).Answer to #3:
That option only changes the method used to authenticate your app to the Keycloak and has nothing to do with the user's token validation inside your app. In your current setup, when your app wants to communicate with Keycloak (e.g. to exchange auth code with auth token), it authenticate itself to Keycloak with a client-id/client-secret pair (otherwise Keycloak would not know it's your app and will reject the request).
If you choose the "Signed Jwt with Client Secret" option, your client can not just use a client-secret to authenticate to Keycloak. It should support the RFC7523 specification. So it's quite complex in compare with a simple clien-secret approach. In an environment in which you trust your clients (e.g. they're all known apps developed inside the company and you're not going to support public clients to join your Keycloak and use its services) it's quite common and safe to use client-secret approach.