例如，在默认的jhipster UAA配置上，我们有：
clients.inMemory()
.withClient("web_app")
.scopes("openid")
.autoApprove(true)
.authorizedGrantTypes("implicit","refresh_token", "password",
"authorization_code")
.and()
.withClient(jHipsterProperties.getSecurity()
.getClientAuthorization().getClientId())
.secret(jHipsterProperties.getSecurity()
.getClientAuthorization().getClientSecret())
.scopes("web-app")
.autoApprove(true)
.authorizedGrantTypes("client_credentials");
那么，"authorizedGrantTypes"在实践中的真正含义是什么？第一个客户端"web_app"将具有不同的类型，包括刷新，因此第二个客户端将能够生成令牌作为client_credentials。有什么区别？
另一个问题，使用"client_credentials"的第二个客户端身份验证的目的是什么？由于这与存储的真实用户断开连接。 微服务到微服务通信？如果配置部署在 Spring 云(客户端和秘密硬编码配置(上以允许通过网关进行任何外部身份验证，则看起来很糟糕。如何预防这种情况？
OAuth 2.0 授权类型是客户端应用程序获取令牌的不同"方式"。
有一堆文章更好地解释了它，但这里有一个摘要：
authorization_code是"经典"OAuth 2.0 流，其中通过重定向要求用户同意。客户端应用程序经过强身份验证，因为它必须发送其所有凭据(client_id+client_secret+redirect_uri(，然后才能获取令牌。implicit与authorization_code几乎相同，但适用于公共客户端(Web 应用程序或已安装/移动应用程序(。从用户的角度来看，流程几乎相同，但客户端身份验证较弱。redirect_uri是唯一的安全性，因为客户端通过重定向 + 请求参数接收访问令牌。password很简单：客户端应用程序收集用户凭据，并发送用户凭据(username+password(和自己的凭据(client_id+client_secret(以换取令牌。此流将授权与身份验证混合在一起，并且应仅在没有其他选择时使用(即您自己的已安装/移动应用程序，您不希望用户在本机应用程序和浏览器之间来回切换(。切勿允许第三方使用此流。
通过所有这些流程，会以一种或另一种方式要求用户获得其许可。提供给客户端的令牌仅允许它访问该单个用户的数据。
授予client_credentials是不同的，因为它不涉及用户。它是HTTP Basic.
的替代品，而不是为每个请求发送用户名(client_id(+密码(client_secret(，而是发送其凭据以换取令牌。
它用于服务器到服务器通信，您希望通过为其提供不同的凭据来了解"哪个应用程序正在调用"，但您不会将其授权与特定用户绑定。
一些例子：
- 使用受保护服务的命令行应用程序(批处理(或工作进程。这种应用程序可能一次处理一堆用户数据，并且它不能请求每个用户的同意。被调用的服务必须知道"谁"在调用，以便允许客户端应用程序访问任何内容。
- 您的 API 的第三方/外部客户端想知道未链接到用户数据的信息(例如：使用情况统计信息、配额、计费......
- 具有特殊权限的第三方/外部客户端，可以访问所有用户的数据
注意：在服务到服务通信中，应中继从外部接收的令牌，而不是让每个中间应用程序请求自己的令牌。