[spring-projects/spring-boot]将 jwt.jwk.set-uri 重命名为 jwt.jwk-set-uri 并重新定位到 spring.security.oauth2.resourceserver

用于在 OAuth 2.0 资源服务器上配置 jwk set uri 的属性是

spring.security.oauth2.resource.jwt.jwk.set-uri

这是明智的，因为它接近遗留 oauth 的属性层次结构。（这仅在叶子中有所不同，在遗留 oauth 中称为key-set-uri。）

用户可以通过以下属性名称更清楚地了解他们正在配置的内容：

spring.security.oauth2.resource-server.jwt.jwk-set-uri

这有几个原因。

首先，在整个 Spring Security 代码库中，资源服务器一直被这样称呼，因此偏离这一点感觉不一致。

虽然对于那些习惯于旧版 oauth 属性集的人来说，“资源服务器”可能会感觉很熟悉，但“资源服务器”更清晰，因为“资源”还带有其他语义含义，包括在整个 Spring 中使用的更普遍的含义，指的是某种外部资产就像文件或数据库一样。

最后，DSL 之间的对称性是有价值的：

http.
    oauth2().
        resourceServer()
            .jwt()

以及属性名称：

spring.security:
  oauth2:
    resource-server:
      jwt:

至于jwk.set-urivs jwk-set-uri，后者在语义上更清晰，因为规范中没有“set-uri”的概念，但有“ JWK Set ”的概念：

JWK Set 表示一组 JWK 的 JSON 对象。 JSON 对象必须有一个“keys”成员，它是一个 JWK 数组。

虽然 JWK Set 是否可以通过 uri 以外的方式进行配置存在争议，但jwk-set.uri它可能不太适合引导来支持我们的其他用例。例如，可以合理地假设用户可能希望手动提供 JWK 集（硬编码）。但是，这不允许用户配置密钥轮换，这对于那些仅需要它进行测试等的人来说是一种边缘情况。

此外，虽然不太重要，但现有 DSL 之间有一个很好的对称性：

http.
    oauth2().
        resourceServer()
            .jwt()
                .jwkSetUri("https://issuer/jwk-set-uri");

以及拟议的财产名称：

spring.security:
  oauth2:
    resource-server:
      jwt:
        jwk-set-uri: https://issuer/jwk-set-uri

jzheaux

我想我很乐意resource改名为resource-server。我们就 slack 进行了讨论，讨论我们是否想要在命名空间set-uri下使用jwk，或者该属性是否应该在jwk-set-uri。添加单独的命名空间的理由是它使将来添加属性变得更容易。如果 JWK 有任何其他配置，则会将其添加到该命名空间下。

mbhave

我不喜欢resource被重命名为，resource-server因为我们不使用破折号来表示组。并为单独的命名空间+1。

snicoll

我不同意将资源重命名为资源服务器，因为我们不使用破折号来表示组。

在考虑这一点时，请考虑当授权服务器支持发挥作用时会发生什么。

如果您坚持使用resource，则表明authorization一致性明智，但这听起来不太好。 IMO 在这种情况下，应保持与主题域的连接级别。也许两者resource和authorization都可以归为一组server？这也很适合与client.

如果 JWK 有任何其他配置，则会将其添加到该命名空间下。

从 subject 中的域的角度来看，正如 @jzheaux 所建议的，这是关于JWK Set而不是JWKset-uri ，并且将其表达为的属性并没有真正意义jwk。相关元数据规范（参见 [1] 和 [2]）将其描述为jwks_uri，并且也没有提及 JWK。

[1] http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata [2] https://tools.ietf.org/html/rfc8414#section-2

vpavic

如果你坚持使用资源

感谢您的反馈，但我从来没有说过我不希望这个小组被重命名。我只是提到我们不会使用多个词来表示群体。

snicoll

我们在 slack 上讨论了是否需要 jwk 命名空间下的 set-uri，或者该属性是否应该是 jwk-set-uri。

是的，你是对的，@mbhave，我应该在票证中提到这一点。在对酒店名称进行进一步内部审查后，我们决定提高这张罚单。

添加单独的命名空间的理由是它使将来添加属性变得更容易。如果 JWK 有任何其他配置，则会将其添加到该命名空间下。

令人担忧的是，我们正在配置的不是 JWK，而是我们正在配置如何验证 JWT，并且一致使用的术语是“JWK Set Uri”（如 @vpavic请注意，jwks_url也用于其中一项规范）。假设，如果我们将 JWK 作为一流的可配置概念引入，那么spring.security.oauth2.resource.jwk可能会更合适，因为 JWK 作为规范并不本质上与 JWT 绑定。

例如，虽然它在语义上较弱，但我们可以调用该属性spring.security.oauth2.resource.jwt.keys-uri，但它仍然是正确的。这里的缺点是我们失去了用户正在配置 jwt 以使用 jwk 集作为其键集的清晰度。

我不同意将资源重命名为资源服务器，因为我们不使用破折号来表示组。

@snicoll，出于我的好奇心，您能解释一下您的团队对此的推理吗？我并不反对，但了解其基本原理将帮助我思考其他可能性。

只是一个快速调查显示了一些多词组，但没有连字符，我想知道您对此有何看法：

spring.mvc.contentnegotiation.favor-parameter spring.mvc.formcontent.putfilter.enabled server.tomcat.accesslog.buffered

只要不使用连字符连接，您可以接受多词组吗？

jzheaux

只要不使用连字符连接，您可以接受多词组吗？

顺便说一句，这不是关于我的，是的，这就是我的意思。原因是前缀（组）应该由用点分隔的单个“单词”构成，并且只有属性具有 kebab 大小写格式才能将其与其余部分正确分隔。

我们已经根据迄今为止在团队电话会议上收到的反馈讨论了这个问题，并提出了一个建议，@mbhave 打算很快总结一下。谢谢！

snicoll

@vpavic @jzheaux 感谢您的解释。我确实明白您关于“JWK Set Uri”用于配置 JWT 验证方式的观点。我同意jwk-set-uri在这种情况下财产更有意义。

对于这一resource-server更改，我们在团队电话会议上讨论了这一点，并决定采用 @vpavic 建议的关于将授权服务器和资源服务器分组到服务器命名空间下的建议。

mbhave

在与 @rwinch 和 @jzheaux 讨论之后，拥有顶级server命名空间似乎没有多大意义。 OAuth 的概念是Resource Server和Authorization server。配置server.authorization似乎意味着我们正在配置服务器的授权而不是授权服务器本身。

@snicoll 如果我错了，请纠正我，但我们不在-组名称中使用，因为它可能会扰乱绑定？ #11090 可能有一些细节。在这种情况下，resourceserver似乎是最好的选择。

mbhave

我们希望集团的结构与财产的结构不同。我们使用点作为查找前缀部分的方法，这可能是环境变量的问题。

snicoll

-在组名称中，因为它可能会扰乱绑定...我们希望组的结构与属性的结构不同

@snicoll，仅就我自己的理解而言，您能否解释一下为什么您希望组的结构与属性的结构不同？听起来部分可能是技术限制，还有其他原因吗？

我仍然认为服务器父级是有意义的

server.resource保留它和有何好处server.authorization？

第一个“服务器资源”读起来像是指服务器上的资源。当单词按此顺序排列时，这是语义上的更仔细的阅读。当然，“服务器资源”与“资源服务器”有很大不同。

第二个“服务器授权”读起来像是指服务器的授权方面，而不是“授权服务器”的配置。

与“JWK Set Uri”这个用于指代其概念的术语非常相似，“资源服务器”是用于指代 OAuth 资源服务器的术语。如果我们查看完整的分组spring.security.oauth2.server.resource，这更像是“OAuth2 服务器”是一个概念，“OAuth2 服务器资源”是正在配置的内容，但事实并非如此。

就像启动中的这个属性一样：

server.tomcat.accesslog.file-date-format

这样做会很混乱：

server.tomcat.log.access.file-date-format

因为这意味着我们正在讨论对日志的访问。由于“log”和“access”都可以互相修改，因此顺序很重要。确实，“accesslog”是人们熟悉且容易理解的术语。

同样，“资源服务器”是工程师在阅读材料和相互讨论时理解和看到的术语。

并且这样做spring.security.oauth2.[client|authorizationserver|resourceserver]还具有以下价值：所有三个 OAuth2 概念在层次结构上都处于同一级别。这很重要，因为每个都是 OAuth2 中的一流实体。

也就是说，OAuth2 不仅仅是一个客户端和一个服务器，而是一个客户端和两个服务器，因此区分正在配置的服务器是很有价值的。因此，“OAuth2 客户端”、“OAuth2 资源服务器”和“OAuth2 授权服务器”等概念是常用术语。

我见过使用术语“OAuth2 服务器”（含糊地）指代“授权服务器”的库。这是不这样做的另一个原因spring.security.oauth2.server.resource，因为人们可能相当合理地推测该属性指的是“OAuth2 授权服务器”配置。

jzheaux

我仍然认为服务器父级是有意义的。

假设这-是不可能的，从更广泛的角度来看，我同意它spring.security.oauth2.resourceserver仍然读起来更好（比），并且与Spring Security OAuth2 资源服务器和配置 DSL 本身spring.security.oauth2.server.resource更一致。

还有像contentnegotiation已经就位的东西，resourceserver并且authorizationserver应该也可以接受。

vpavic

同意@vpavic，这就是为什么我编辑我的评论以删除我的评论的那部分并防止更多评论。我能看到已经太晚了:) - 根据记录，我只提到了server收集这些道具的一种方式。再说一遍，我从来没有暗示过server.resource。我想我们resourceserver现在已经被卖掉了。

snicoll

@斯尼科尔

使用resourceserverand laterauthorizationserver对我来说听起来不错。

对于我（我们）自己的教育，你能详细说明一下吗？

-1）团队结构中存在哪些问题会导致？ 2）为什么“我们希望集团的结构与财产的结构不同”

rwinch

@rwinch

团体结构中存在 - 会导致什么问题？

在前缀中使用破折号是有问题的，因为它们不遵循与名称相同的绑定规则。它基本上会引起很多混乱，所以我们尽量不使用它们。例如，给定 a@ConfigurationProperties("foo.bar")和 a field firstName，您可以使用以下任一方式进行绑定：

foo.bar.first-name // canonical
foo.bar.firstName // java style
FOO_BAR_FIRSTNAME // environment variable

如果前缀是foo-bar“java风格”和“环境变量风格”开始看起来很奇怪。

philwebb

[spring-projects/spring-boot]将 jwt.jwk.set-uri 重命名为 jwt.jwk-set-uri 并重新定位到 spring.security.oauth2.resourceserver

回答