Auth Servers 的 openid 配置中 URL 的最佳实践(众所周知)

Posted

技术标签:

【中文标题】Auth Servers 的 openid 配置中 URL 的最佳实践(众所周知)【英文标题】:Best practices for URLs in openid configuration (well-known) for Auth Servers 【发布时间】:2021-10-02 07:50:07 【问题描述】:

URL 规范明确指出部分 URL 可以区分大小写。因此,人们可以清楚地使用他们认为合适的任何情况。

Open ID Connect 的 Well-known 端点配置是授权服务器发布的东西(一旦发布,这些值很可能一成不变)。

注意到有一个使用大写 JWKS 的 jwks URI 的身份供应商。

这听起来很奇怪 - 他们不仅选择使用 JWKS(大写),而且还不允许更改该值!!。

查看了巨头(Google、Microsoft)和其他身份领导者(例如 Auth0、Okta)使用的著名 Config URI/URL 模式,所有 URI 都使用小写值。

这是来自使用 Okta 的 local University 的示例。我查看了很多示例,但我很难找到使用大写字母作为其 Open ID 知名配置 URL 的示例。

在这个领域有领先玩家采用/拥护的最佳实践吗?

此空间中是​​否有可供人们遵循的文档?

从Queensland Govt 找到一个关于 URL 设计指南的好资源(通用的,但发现它非常全面且经过深思熟虑)。

对于那些在他们的解决方案中考虑 URL 的人来说,这可能是一个很好的资源

【问题讨论】:

【参考方案1】:

最好的做法是小写,长名称用连字符 - 几乎每个人都采用这种做法,虽然也有一些不好的玩家。

URL 的某些部分被指定为不区分大小写,因此服务器应该接受任何大小写混合 - 尽管我个人不会在没有测试的情况下依赖它:

scheme,例如 HTtps domain name,例如 myCOMPANY.com

URL 的其他部分(例如 JWKS)可能区分大小写,也可能不区分大小写 - 在 Windows/MacOS 上可能无关紧要 - 但 Linux 往往最严格。

总而言之,我总是创建自己的 URL 或那些我可以影响大小写的 URL - 在某些情况下,我需要接受我提供的内容。

【讨论】:

以上是关于Auth Servers 的 openid 配置中 URL 的最佳实践(众所周知)的主要内容,如果未能解决你的问题,请参考以下文章

Auth0 express-openid-connect 指定 IDP 与连接

如何将 OPENID auth 集成到 REST api 和前端框架架构中

使用 Auth0 的 Azure 应用服务 OpenID 身份验证失败:值不能为空。 (参数'rawToken')

keycloak 错误 http://localhost:8080/auth/realms/claim-dev/protocol/openid-connect/token

HTTP验证大法(Basic Auth,Session, JWT, Oauth, Openid)

如何在 IAM 角色的信任策略中检查自定义 OpenID 声明?