您何时使用 OpenID 与 OpenID Connect

信息安全 验证 oauth 授权 打开ID 开放式连接
2021-08-21 01:05:14

它们可以一起使用吗？....或者它们是两个独立的协议，根据上下文可能有用也可能没用？

我问的原因是因为我正在尝试实现以下内容：

  1. 用户“Bob”转到作为仅用户代理应用程序实现的客户端。
  2. 受保护的资源由与认证/授权服务器相同的域控制，但它们位于不同的子域上。但是，在 cookie 中没有找到会话，所以...

  3. Bob 单击“登录”，并使用以下内容重定向到授权/身份验证服务器：

    GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token custom

  4. Bob 有一个选项列表可供选择以进行身份​​验证，即“example、google、twitter”等，这导致他在 example.com 上进行身份验证，而后者又用于他对 example 托管的特定 API 的授权.com。

我应该同时使用 OpenID Connect、OpenID 2.0 吗？什么？这是我第一次实施其中任何一个。我只是在询问身份验证部分。我只是想让 Bob 进行身份验证，以便继续向客户端颁发令牌。

3个回答

我认为之前的其他任何一个回答都没有回答这个问题，即询问和之间的OpenID Connect区别OpenID 2.0。 OpenID 2.0不是OAuth 2.0。

OpenID 2.0并且OpenID Connect是非常不同的标准，具有完全不同的参数和响应正文格式。两者都建立在OAuth 2.0通过将附加值放入其他有效OAuth 2.0请求和响应的基础上，以提供身份验证所需的身份信息（而OAuth 2.0仅提供授权，不提供身份验证）。OpenID Connect 改进了字段和参数的命名和结构，OpenID 2.0以便于使用。我可以轻松阅读OpenID Connect规范并了解所有值的用途以及将它们设置为什么，但尝试阅读OpenID 2.0规范有点困难和复杂。

此时选择很容易，OpenID 2.0已弃用。你应该使用OpenID Connect.

OpenID 和 OpenID Connect 都用于身份验证，而不是用于授权。这两个活动是不同的。OpenID Connect 实际上是 OAuth（一种授权协议），它被转换（滥用）为一种身份验证协议。此答案中有更多解释。

在某种程度上，您可以混合身份验证和授权，但这会造成混淆。在您的情况下，您显然希望使用“Google，Twitter，...”对用户进行身份验证：您希望 Google（或 Twitter）告诉您用户是谁，而不是应该允许用户做什么；您希望这些外部提供者进行身份验证，而不是授权。

另一种查看方式如下：用户连接到您的服务器S。服务器S提供一些“服务”，即会在被要求时做“事情”；但是，它不会接受为每个人做同样的事情。让我们假设您发现将S可以为每个用户做什么或不做什么的控制权交给另一个我们称为R的系统是合适的。R可能与S是同一台计算机，也可能不是同一台计算机，但让我们笼统地思考并假设R与S不同。从S的角度来看，所需的信息在授权范围内：S想知道呼叫是否被授予。所以在S和R之间会有一些授权协议。可能，S和R不会直接相互通信，而只能通过客户端传输的消息（“票证”）；这是一个技术细节。

但是，要决定是否允许对S的给定请求，授权服务器R必须知道谁在发送请求，因为答案取决于用户的身份。因此，R将需要对用户进行身份验证；或者，更一般地说，与认证服务器T对话。T负责确保用户确实是他声称的那个人。然后在R和T之间发生身份验证协议。

在您的示例中，R是您的授权服务器，而T是 Google/Twitter。您将在R和T之间使用 OpenID ，在S和R之间使用 OAuth 。

OpenID Connect 是S也想做一些身份验证的时候；然后S使用R（“说 OAuth”）并推断如果R允许请求，那么R必须对用户进行了某种身份验证；所以S决定用户确实是他声称的那个人，因为它（隐含地）说服了R。

OAuth 只提供并且应该只提供使用访问令牌的授权。OpenID connect 基于 OAuth 2 构建，以提供用户身份验证信息。OpenID connect 实际上是 OpenID 的子节点。参见 OpenID-Connect-Lecture-for-MIT，幻灯片 33

OpenID Connect 1.0 是 OAuth 2.0 [RFC6749] 协议之上的一个简单身份层。它使客户端能够根据授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终​​用户的基本配置文件信息。OpenID Connect Core 1.0 - 草案 17

事实是，OpenID connect 为您提供了一种获取用户身份的“标准”方式。如果您使用 OAuth 和 API，您应该针对每个资源调整您的请求，这些资源可能并不总是提供相同的信息，或者可能会随着时间而改变。从概念上讲，您使用 OAuth 是为了被允许使用 API，而不是对用户进行身份验证。

作为背景，OAuth 2.0 授权框架 [RFC6749] 和 OAuth 2.0 承载令牌使用 [RFC6750] 规范为第三方应用程序获取和使用对 HTTP 资源的有限访问权提供了一个通用框架。它们定义了获取和使用访问令牌来访问资源的机制，但没有定义提供身份信息的标准方法。值得注意的是，如果不分析 OAuth 2.0，它就无法提供有关最终用户身份验证的信息。OpenID Connect Core 1.0 - 草案 17

请注意，OpenID connect 提供了一个 id_token ，其中包含有关用户的一些信息。但是如果你想要整套信息，你仍然需要 access_token 来请求 OpenID 提供者获取用户信息（这让我第一次看到它时感到困惑）。见5.3.1. userinfo request草稿

其它你可能感兴趣的问题
上一篇在 PHP 中清理用户输入的最佳方法是什么？ 下一篇更强大的 SSH 密钥加密