Fantastic news! The implementation of Role-based Access Control on the Resource Server has been accomplished. The two issues mentioned in the previous articles have been resolved.
The initial issue was the absence of scope within the GrantedAuthorities on the Resource Server. To address this, I developed a JWT Token Decoder for the Resource Server, enabling the conversion of scope into GrantedAuthorities.
Upon logging into the Client, I encountered an issue with the Client Credential Authorization Method Grant. Unlike the Authorization Code Grant and Device Code Grant, which functioned correctly, the Client Credential Grant was not connected to the Resource Server.
The is because both the Authorization Code Grant and Device Code Grant require user permission, whereas the Client Credential Grant does not necessitate user interaction. Consequently, the Client directly accesses the Resource Server using OAuth2ClientAuthenticationToken. In contrast, the former two grants use UsernamePasswordAuthorizationToken.
Within the JWT Encoder on the Authorization Server, the Token follows the structure of UsernamePasswordAuthorizationToken. This format allows authorities to be added to the JWT Token as an additional claim. However, the OAuth2ClientAuthorizationToken lacks this supplementary claim.
Upon passing the JWT Token to the Decoder on the Resource Server, an issue arose due to the OAuth2ClientAuthorizationCode lacking the extra claim of authorities. To address this, I made modifications to the Decoder.
Initially, we checked if this claim existed. If it did, I proceeded to convert it into a GrantedAuthority. This adjustment resolved the issue, and subsequently, the Client Credential Grant was able to successfully access the Resource Server.
This represents a comprehensive interaction among the Authorization Server, Resource Server, and Client, successfully implementing Role-based Access Control.
My upcoming task involves refining the PTE Resource Server. This includes importing pre-arranged PTE questions into the MongoDB database and VPS server, verifying their accessibility for `Clients, and ensuring access restrictions based on different user access levels.
太好啦！资源服务器的Role-based Access Control实现啦！
上篇文章提到的两个问题都解决了
第一个问题是scope在资源服务器的GrantedAuthorities缺少，我就在资源服务器的JWT Token Decoder把scope转换为GrantedAuthorities的步骤加上去了。
然后我登录客户端，发现Client Credential这种认证方式出错了，而Authorization Code和Device Code 没有问题。这是因为Authorization Code和Device Code都需要用户的授权，走的是UsernamePasswordAuthenticationToken，而Client Credential不需要用户授权，客户端直接访问资源服务器，走的是OAuth2ClientAuthenticationToken。我在认证服务器的JWT Encoder中当Token是UsernamePasswordAuthorizationToken时，它才有authorities，我就把它添加到JWT token中，作为额外的一个claim。而OAuth2ClientAuthorizationToken就没有这项。
当JWT Token传到资源服务器Decode的时候，OAuth2ClientAuthorizationCode没有额外的authorities这个claim，就出错了。我修改了下这个Decoder，先判断有没有这个claim，有我就转换为GrantedAuthority，错误就解决啦！Client Credential也可以正常访问资源服务器。
这下完整的一套认证服务器，资源服务器和客户端的交互以及Role-based Access Control都实现了。
我下面的目标是完善我的PTE的资源服务器，我要把题目先在本地导到MongoDB数据库中，然后在客户端在看是否能读取，以及有着不同权限的用户是否可以有相应的访问!-