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

Question

例如,在默认的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云(客户端和秘密硬编码配置)上以允许通过网关进行任何外部身份验证,那么看起来很糟糕.怎么预防这个？

Answer 1

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的替代品.您的客户端
不会为每个请求发送username(client_id)+ password(client_secret),而是发送其凭据以换取令牌.

它用于服务器到服务器通信,您希望通过为其提供不同的凭据来了解"正在调用哪个应用程序",但您不会将其授权与特定用户绑定.

一些例子 :

• 消耗安全服务的命令行应用程序(批处理)或工作进程.这种应用程序可能会立即处理一堆用户数据,并且不能请求每个用户同意.被调用的服务必须知道"谁"正在调用,以便允许客户端应用程序访问任何内容.
• 您的API的第三方/外部客户端想要知道未链接到用户数据的信息(例如:使用情况统计信息,配额,结算...)
• 具有特殊权限的第三方/外部客户端,可以访问所有用户的数据

注意:在服务通信中,您应该中继从外部接收的令牌,而不是让每个中间应用程序请求其自己的令牌.