OpenIDConnect 响应类型混淆

Posted 2023-03-04

【中文标题】OpenIDConnect 响应类型混淆

【英文标题】：OpenIDConnect Response Type Confusion

【发布时间】：2015-05-30 07:02:21

【问题描述】：

过去几天我已经阅读了有关 OAuth2 和 OpenIDConnect 的所有规范，并使用 Thinktecture Identity Server 实现了一个测试客户端。我还参加了几门复数课程，我认为了解它的主要要点。但是我仍然对响应类型感到非常困惑。

OpenIDConnect 规范指定混合流响应类型是“code”、“id_token”和“token”的组合。我了解“id_token”允许我们最初访问基本的身份信息。

我也理解代码”是指授权代码，“令牌”是指访问令牌，将“代码”与其他两个之一或两者结合会触发流程，但我的理解是您将授权代码换成授权流程中的访问令牌，而隐式流程隐式提供访问代码？

有人能解开我的困惑吗？

【参考方案1】：

您的以下陈述是正确的：

code 指授权码 token 指的是访问令牌或 (access_token) 在授权代码流程中，将code 切换为access_token

但您的部分困惑可能源于术语混淆：

“授权流程”一词并不完全正确；它的正式名称是授权码流 访问代码一词不存在 隐式流没有授权代码（也没有访问代码），实际上根本不涉及允许客户端从令牌端点获取令牌的凭据（或 grant），因此它是姓名

正如@juanifioren 所指出的，混合流结合了事物：

code id_token 流将直接在身份验证响应中获得code 和id_token，但您可以使用code 从令牌端点获得access_token code token 流将直接在身份验证响应中获得code 和access_token，但您将使用code 从令牌的后端获得id_token 和可能的另一个access_token端点 code id_token token 流将在身份验证响应中直接获得code、access_token 和id_token

并且

您可以在后端使用code 来获得

另一个

来自令牌端点的access_token

从令牌端点获取access_token 不同于从授权端点获取它，因为机密客户端向令牌端点（而不是授权端点）验证自己的身份。因此，客户端机密部分的access_token 可能具有更多权限和/或更长的寿命。

另请参阅规范邮件列表中有关此主题的简短主题：http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150209/005229.html

【讨论】：

感谢您清理术语 - 我仍然不确定为什么我需要来自 token_endpoint 的第二个 access_token？是不是因为我可能有一个可以同时使用这两种流程的应用程序？

是的，如果您的应用程序能够同时处理两个流程，则它可以获得 2 个访问令牌；它可能会选择这样做，因为它比前端渠道更信任反向渠道流

另一个原因是刷新令牌仅在反向通道上发布。您永远不会使用隐式流获得刷新令牌，因此在混合流期间从授权端点返回的令牌也应该如此。

【参考方案2】：

要了解响应类型和授权类型之间可能存在的关系，请参阅IdentityServer4\Constants.cs

public static readonly Dictionary<string, string> ResponseTypeToGrantTypeMapping = new Dictionary<string, string>
        
             OidcConstants.ResponseTypes.Code, GrantType.AuthorizationCode ,
             OidcConstants.ResponseTypes.Token, GrantType.Implicit ,
             OidcConstants.ResponseTypes.IdToken, GrantType.Implicit ,
             OidcConstants.ResponseTypes.IdTokenToken, GrantType.Implicit ,
             OidcConstants.ResponseTypes.CodeIdToken, GrantType.Hybrid ,
             OidcConstants.ResponseTypes.CodeToken, GrantType.Hybrid ,
             OidcConstants.ResponseTypes.CodeIdTokenToken, GrantType.Hybrid 
        ;

【参考方案3】：

您对授权代码流和隐式流的想法是正确的。 但是我认为您使混合流程过于复杂。使用混合时，您只需简单地获取代码和 id_token。

之后，您可以获取代码并将其交换为访问令牌，或者直接使用 id_token（或访问令牌）。这两种方法都有自己的缺陷，尤其是在安全方面。

【讨论】：

您所说的对于“code id_token”response_type 是正确的，但也定义了“code token”和“code id_token token”字符串。当您想要 response_type 的这些值时，现实世界的用例是什么？该规范没有给我们任何提示，坦率地说我不知道​​。总的来说，我认为混合流的优势在于签名和加密的 id_token 为未受保护的前端通道的通信增加了安全性，特别是如果您的客户端使用来自预先注册的 jwks 的密钥。 （顺便说一句，您可以比较 Gluu Server LDAP 中的令牌以查看差异。）

【参考方案4】：

https://medium.com/@darutk/diagrams-of-all-the-openid-connect-flows-6968e3990660#9401

6. response_type=代码令牌

response_type的值为code token时，授权码 并且从授权端点发出访问令牌，并且 访问令牌是从令牌端点发出的。另外，如果openid 包含在范围请求参数中，ID 令牌是从 令牌端点也是如此。

授权端点和令牌端点都发出访问权限 令牌，但访问令牌的内容并不总是相同的。 对此，“3.3.3.8. OpenID Connect Core 1.0 中的“访问令牌” 说如下：

如果从两个授权端点返回访问令牌 并来自令牌端点，response_type 就是这种情况 values code token 和 code id_token token，它们的值可能是 相同或可能不同。请注意，不同的访问令牌可能 被退回是由于不同的安全特性 两个端点以及生命周期和对资源授予的访问权限 它们也可能不同。