spring-security-oauth2授权DGRANTYPE的配置在实践中意味着什么？

例如，在默认jhipster UAA配置上，我们有：

clients.inMemory（）
.withClient（“web_应用程序”）
.scopes（“openid”）
.autoApprove（true）
.authorizedGrantTypes（“隐式”、“刷新令牌”、“密码”，
“授权代码”）
.及()
.withClient（jhipsterpreproperties.getSecurity（）
.getClientAuthorization（）.getClientId（））
.secret（jhipsterpreproperties.getSecurity（）
.getClientAuthorization（）.getClientSecret（））
.scopes（“web应用程序”）
.autoApprove（true）
.authorizedGrantTypes（“客户证书”）

那么，“授权类型”在实践中究竟意味着什么呢？第一个客户端“web_应用程序”将具有不同的类型，包括刷新，因此第二个客户端将能够生成令牌作为客户端_凭据。有什么区别

另一个问题是，使用“客户机凭据”的第二个客户机身份验证的目的是什么？因为它与存储的真实用户断开连接。微服务到微服务的通信？如果配置部署在spring云上（客户端和机密硬编码配置），以允许通过网关进行任何外部身份验证，则看起来很糟糕。如何防止这种情况？
是客户端应用程序获取令牌的不同“方式”

对此有很多解释，但这里有一个总结：


authorization\u code
是OAuth 2.0的“经典”流程，通过重定向请求用户同意。客户端应用程序是经过强身份验证的，因为它必须先发送其所有凭据（
client\u id
+
client\u secret
+
redirect\u uri
），然后才能获得令牌
隐式
几乎与授权代码相同，但适用于公共客户端（web应用程序或已安装/移动应用程序）。从用户的角度来看，流程几乎相同，但客户端身份验证较弱。
redirect\u uri
是唯一的安全机制，因为客户端通过redirection+请求参数接收访问令牌
password
很简单：客户端应用程序收集用户凭据，并发送用户凭据（
username
+
password
）及其自己的凭据（
client\u id
+
client\u secret
），以交换令牌。此流程将授权与身份验证混合在一起，仅在没有其他选择时使用（即，您自己的安装/移动应用程序，您不希望用户在本机应用程序和浏览器之间来回切换）。您应该绝不允许第三方使用此流

在所有这些流中，用户都会以某种方式请求其权限。给客户端的令牌只允许它访问单个用户的数据

client\u凭证
grant是不同的，因为它不涉及用户。它是HTTP Basic的替代品。

不是为每个请求发送用户名（
client\u id
）+密码（
client\u secret
），而是客户端发送其凭据以交换令牌

它用于服务器到服务器的通信，在这种通信中，您希望通过提供不同的凭据来了解“哪个应用程序正在调用”，但不将其授权与特定用户绑定

一些例子：


使用安全服务的命令行应用程序（批处理）或工作进程。这种应用程序可能一次处理一组用户数据，并且不能请求每个用户的同意。被调用的服务必须知道“谁”在调用，以便允许客户端应用程序访问任何内容
API的第三方/外部客户端希望了解未链接到用户数据的信息（例如：使用情况统计、配额、计费…）
具有特殊权限的第三方/外部客户端，可以访问您所有用户的数据


注意：在服务到服务的通信中，您应该中继从外部接收到的令牌，而不是让每个中间应用程序请求自己的令牌。
回答得很好。你能解释一下作用域“读”、“写”、“信任”的作用吗？或者它们是任意的/用户定义的？范围是权限，因此它们实际上是特定于业务的（请参见或示例）。就像Spring Security的权威一样，要获得正确的粒度非常困难，而且没有神奇的答案。谢谢！这就是我一直在寻找的答案