OpenIDConnect响应类型混淆 [英] OpenIDConnect Response Type Confusion

问题描述

最近几天，我已经阅读了有关OAuth2和OpenIDConnect的所有规范，并使用Thinktecture Identity Server实现了测试客户端.我也参加了几门多元化的课程，我想了解它的主要要旨.但是，我仍然对响应类型感到非常困惑.

I've spend the last few days reading through all the specs with regards to OAuth2 and OpenIDConnect and implementing a test client using Thinktecture Identity Server. I've also followed several pluralsight courses and I think understand the main gist of it. However i'm still extremely confused about the Response Types.

OpenIDConnect规范指定混合流响应类型是代码"，"id_token"和令牌"的组合.我了解"id_token"可以使我们最初获得基本的ID信息.

OpenIDConnect spec specifies that the Hybrid flow response types are a combination of "code", "id_token" and "token". I understand the "id_token" allows us to get access to basic id information initially.

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

I also understand code" refers to the authorization code and "token" refers to an access token and combining "code" with one or both of the other two triggers the flow but my understanding was that you swap an authorization code for an access token in the Authorization flow, while the Implicit flow supplies the Access Code implicitly?

有人可以消除我的困惑吗?

Could someone clear up my confusion?

推荐答案

您所做的以下陈述是正确的:

The following statements that you made are correct:

• code 是指授权码
• 令牌是指访问令牌或( access_token )
• 在授权码"流中，将 code 切换为 access_token

• code refers to the Authorization Code
• token refers to an Access Token or (access_token)
• in the Authorization Code flow one switches the code for an access_token

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

But part of your confusion may originate from terminology mixup:

授权流程"一词并不完全正确；它的正式名称是授权码流"
• 访问代码一词不存在
• 隐式流没有授权码(也不是访问码)，实际上根本没有任何凭证(或 grant )可以使客户端从Token端点获取令牌，因此它是名称

• the term Authorization flow is not entirely correct; its official name is Authorization Code flow
• the term Access Code does not exist
• the Implicit flow does not have an Authorization Code (nor Access code) in fact there's no credential (or grant) involved at all that allows the Client to get tokens from the Token endpoint, hence it's name

正如@juanifioren所指出的，混合流结合了以下内容:

As @juanifioren pointed out, Hybrid flows combine things:

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

• the code id_token flow would get a code and id_token in the Authentication Response directly but you'd use the code to get an access_token from the Token endpoint
• the code token flow would get a code and access_token in the Authentication Response directly but you'd use the code to get an id_token and possibly another access_token in the backend from the Token endpoint
• the code id_token token flow would get a code, access_token and an id_token in the Authentication Response directly and you could use the code in the backend to get another access_token from the Token endpoint

从令牌端点获取 access_token 与从授权端点获取它不同，因为机密客户端向令牌端点(而不是授权端点)进行身份验证.因此，客户端机密部分的 access_token 可能具有更多权限或更长的使用寿命.

Getting an access_token from the Token endpoint differs from getting it from the Authorization endpoint because the confidential clients authenticate themselves to the Token endpoint (and not to the Authorization endpoint). Hence the access_token for the confidential part of the client might have more permissions and or a longer life.

另请参阅有关此主题的规范邮件列表上的简短主题:

See also a short thread on the spec mailing list on this topic: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150209/005229.html

这篇关于OpenIDConnect响应类型混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！