IDaaS储备知识2 - 基于OAuth 2的OIDC认证

基于OAuth2的认证

OAuth 2.0 规范定义了一个授权（delegation）协议，对于使用Web的应用程序和API在网络上传递授权决策非常有用。OAuth被用在各钟各样的应用程序中，包括提供用户认证的机制。这导致许多的开发者和API提供者得出一个OAuth本身是一个认证协议的错误结论，并将其错误的使用于此。让我们再次明确的指出：OAuth2.0 不是认证协议。

混乱的根源来自于在认证协议的内部实际上使用了OAuth，开发人员看到OAuth组件并与OAuth流程进行交互，并假设通过简单地使用OAuth，他们就可以完成用户认证。这不仅不是事情的真相，而且对服务提供商，开发人员以及最终用户而言都是危险的事情。

本文旨在帮助潜在的身份提供者如何基于OAuth2构建用户身份认证。实际上，如果你说“我有OAuth2，并且我需要身份认证”，那么请继续阅读。

什么是认证（Authentication）？

     在用户访问一个应用程序的上下文环境中认证会告诉应用程序当前用户是谁以及其是否存在。一个完整的认证协议可能还会告诉你一些关于此用户的相关属性，比如唯一标识符、电子邮件地址以及应用程序说“早安”时所需要的内容。认证是关于应用程序中存在的用户，而互联网规模的认证协议需要能够跨网络和安全边界来执行此操作。

然而，OAuth没有告诉应用程序上述任何信息。OAuth对用户没有任何说明，也没有说明如何证明他们的存在，即使他们就在那里。对于OAuth的Client而言，它请求一个token，得到一个token，并用这个token访问一些API。但它不知道是谁授权的应用程序，以及甚至还有一个用户在那里。实际上，OAuth的大部分问题在于Client和被访问的资源之间的连接上在用户不存在的情况下使用这种委托访问。这对于Client授权来说是好的，但是对于用户身份认证来说却非常糟糕，因为认证需要确定用户是否存在（以及他们是谁）。

另外一个的混淆的因素，一个OAuth的过程通常包含在一些认证的过程中：资源所有者在授权步骤中向授权服务器进行身份验证，客户端向令牌端点中的授权服务器进行身份验证，可能还有其他的。OAuth协议中的这些认证事件的存在不能够说明OAuth协议本身能够可靠地传送认证。（译注：我觉得可能作者想表达的是虽然OAuth是这些认证事件的消费者，但却不是生产者，所以不能因为使用了认证，就等同于OAuth可以直接提供认证。）

事实证明尽管如此，还有一些事情可以和OAuth一起使用，以便在授权和授权协议之上创建身份认证协议。几乎在所有的这些情况下，OAuth的核心功能都将保持不变，而发生的事件是用户将他们的身份委派给他们正在尝试登录的应用程序。然后，客户端应用程序成为身份API的消费者，从而找出先前授权给客户端的用户。以这种方式建立身份验证的一个主要好处是允许管理最终用户的同意，这在互联网规模的跨域身份联合中是非常重要的。另一个重要的好处是，用户可以同时将访问其他受保护的API委托给他们的身份，使应用程序开发人员和最终用户管理更简单。通过一个调用，应用程序可以找出用户是否登录，应该调用什么用户，下载照片进行打印，并将更新发布到其消息流。这种简单性是非常有吸引力的，但当这两件事情同时进行时，许多开发人员将这两个功能混为一谈。

<