OAuth 授权与身份验证答案

【问题标题】：OAuth Authorization vs AuthenticationOAuth 授权与身份验证
【发布时间】：2016-02-15 15:07:00
【问题描述】：

OAuth 术语已经困扰我很久了。是像某些人建议的那样进行 OAuth 授权还是身份验证？

如果我错了，请纠正我，但我一直将授权视为允许某人访问资源的行为，但 OAuth 似乎没有任何实际允许用户访问给定资源的实现。所有 OAuth 实现都在谈论为用户提供一个令牌（签名，有时加密）。然后，每次调用都会将此令牌传递给后端服务端点，在该端点检查其有效性，这同样不是 OAuth 问题。

我认为 OAuth 身份验证（每篇文章都说不是）是否需要用户提供凭据，进而证明用户应该/不应该拥有访问权限？

因此，OAuth 似乎不是授权或身份验证，因为这些必须由其他进程执行。那到底是什么？它是一个传递令牌的过程吗？是真的没有具体含义的绒毛词吗？

很难在不听起来神秘和迷信（鬼怪和妖精）的情况下提出关于这个主题的问题，所以我希望回答这个问题也不会是一件简单的事情。输入您自担风险。

【问题讨论】：

【解决方案1】：

OAuth 是一种授权规范

OAuth 2.0 是授权规范，但不是身份验证规范。 RFC 6749，3.1. Authorization Endpoint 明确表示如下：

授权端点用于与资源所有者交互并获得授权。授权服务器必须首先验证资源所有者的身份。的方式授权服务器对资源所有者进行身份验证（例如，用户名和密码登录、会话 cookie）超出了此范围规范。

身份验证处理有关“谁是”的信息。授权处理有关“谁向谁授予什么权限”的信息。授权流程包含身份验证作为其第一步。这就是人们经常感到困惑的原因。

有许多库和服务使用 OAuth 2.0 进行身份验证。它通常被称为“社交登录”，它使人们更加困惑。如果您看到“OAuth 身份验证”（不是“OAuth 授权”），这是使用 OAuth 进行身份验证的解决方案。

OpenID 1.0 和 OpenID 2.0 是旧的身份验证规范。制定规范的人希望人们使用 OpenID 进行身份验证。但是，有些人开始使用 OAuth 2.0 进行身份验证（而不是授权），并且 OAuth 身份验证迅速盛行。

从 OpenID 人的角度来看，基于 OAuth 的身份验证不够安全，但他们不得不承认人们更喜欢 OAuth 身份验证。因此，OpenID 人员决定在 OAuth 2.0 之上定义一个新规范 OpenID Connect。

是的，这让人们更加困惑。

OAuth 2.0 是一个框架，服务的用户可以允许第三方应用程序访问他/她在服务中托管的数据，而无需透露他/她的凭据（ID 和密码）到应用程序。

OpenID Connect 是 OAuth 2.0 之上的框架，第三方应用程序可以在其中获取由服务管理的用户身份信息。

^{（对不起，这些定义摘自我公司overview页面）}

身份验证 是确定最终用户的主题（= 唯一标识符）的过程。有很多方法可以确定主题。 ID&密码、指纹、虹膜识别等

授权是将主题与请求的权限以及请求权限的客户端应用程序相关联的过程。访问令牌代表关联。

【讨论】：