我正在构建一个服务提供商应用程序，其中用户应该能够使用OAuth2和OpenID Connect与第三方应用程序共享他们的数据。
标准OAuth2同意流授权范围（共享哪些属性/角色）。但是，由于属性可能包含多个值，我们还希望允许用户选择要共享的值。
所以我的问题是，我应该用一个定制的流程来替换整个OAuth2同意流程吗？在这个流程中，OAuth2作用域或多或少地被显式属性键/值对所替换。删除OAuth2的核心组件（如作用域）感觉有点奇怪，你怎么看？还有其他建议吗？
我目前正在试用spring授权服务器来定制同意流（因为我们目前使用的Keycloak在同意逻辑方面似乎不太灵活）。
我认为在spring授权服务器中替换标准同意流需要重写OAuth2 AuthorizationConsentService、OAuth2 AuthorizationConsentAuthenticationProvider以及用于身份验证的所有OAuth2...AuthenticationProvider类，以便将同意转发到新的同意流。
2条答案
按热度按时间kqqjbcuj1#
您所描述的正是范围的确切目的：包含用户对特定客户端可以代表其访问哪些数据（属性名称）的同意。通常，为了简化用户选择和软件维护，范围选择中的属性粒度与内部数据模型不同（例如，
contact范围可以表示数据库中的电话、国家/地区、城市、邮政编码和街道列）由于角色、组、权限或任何应该Map到Spring权限的东西都不是由Oauth2或OpenID指定的，授权服务器使用私有声明来存储这些数据（通常不是作用域）。如果你习惯于Keycloak，你应该注意到角色默认放在
realm_access.roles和resource_access.{client-id}.roles中。其他授权服务器将使用其他私有声明。简单地说，角色（或组或权限，或您想称之为它的任何东西）定义了特定的用户在系统中可以做什么，而作用域应该包含允许特定的客户机代表该用户访问哪些资源。
e0bqpujr2#
我想我应该添加一些基于用例的注解，说明所涉及的各方，以及同意是如何工作的。
客户
客户端应用程序只是使用范围参数进行重定向。可以发送声明参数，但很少使用。范围可能是
profile，由name和date of birth声明组成。授权服务器
这将在同意屏幕中显示所需的信息。最灵活的方法是显示声明，如复选框。一些声明，如姓名，可能被标记为必填项并使用禁用复选框。其他声明，如出生日期，可以是可选的。用户可以取消选择后一个声明，然后它将不包括在所发放的令牌中。
自定义同意书
理想情况下，不需要定制就可以实现上述功能，这应该是开箱即用的。但Spring可能不是这样。定制同意是有效的。一个有趣的例子是在Open Banking中，用户可以同意支付运行时的金额：