我正在阅读带有OAuth 2.0令牌的关于jwt的{{3}}。有趣的是作者描述client_secret时，他说：
在非平凡的实现中，客户端ID和密码将安全地存储在数据库中，并可通过客户端应用程序在部署期间访问的单独API进行检索。
现在让我们说我有一个带有角度的前端应用程序，一个带有MySQL db的春季后端应用程序。
我的问题是上述引用所指的作者是什么。是那个吗
客户（在这种情况下为前端应用）使用client_id拨打电话
和secret（此处没有任何变化），但后端正在检查
提供的“凭据”不是通过与以纯文本格式存储的值（在
application.properties），但根据接收到的值和
与db中的哈希版本进行比较？
已编辑： article
john doe打开log in页面。提供凭据：username:john.doe和password:john1。点击sign in。obtainTokenForUser()），以便为用户获取一个短期有效的jwt令牌。因此，angular-app向OAuth2.0发送了authorization server兼容请求。发送附件AWS KMS以获得其client_id和secret以便附加到请求之前。最后，从角度到身份验证服务器的请求看起来像：curl front-app-sp3:frnt4pP@<auth_server_ip_addr>:<auth_server_port>/oauth/token -d grant_type=password -d username=john.doe -d password=john1 Authorization server联系人AWS KMS与收到的client_id:front-app-sp3和client_secret:frnt4pP的联系人。它找到条目，密码匹配，验证正确。 Auth server产生有效的JWT令牌5 minutes。服务器使用AS_pr1v4t3私钥对令牌进行签名。 Authorization server向令牌应用返回令牌。Resource server验证令牌。令牌正确有效。资源已返回。答案 0 :(得分：1)
我认为这不是作者所指的。 （S）他正在谈论的不是在您的application.properties中包含select user.*, count(call_out_end.id) as calls
from user
left join call_out_end
on call_out_end.employer_id = user.id
where
user.id = 949
and (
call_out_end.employer_id IS NULL
or call_out_end.callstart >= '2018-12-09 00:00:00'
)
group by user.id
和client_id，而是将它们存储在DB中，您的后端可以通过不同的API访问它们。我认为client_secret比秘密管理服务更属于application.properties。 您的前端（在这种情况下为角度应用程序）绝对不能访问客户端ID或机密。 Angular应用程序连接到的服务器（我想通过某些REST服务）也绝对不能直接访问机密，它应该通过单独的机密管理API。您的服务器可以使用{ {1}}，但应将秘密存储在非常安全的位置。
这是一个已经实现的模式。与其直接在app.config / application.properties文件中保存机密值，不如将它们放在类似以下的位置：
这些可以让您存储/更新/检索和旋转您的秘密。