OAuth授权与身份验证

Question

OAuth术语已经困扰我很久了。OAuth授权是像一些人建议的那样，还是认证？

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

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

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

要问一个关于这个主题的问题很难不让人觉得神秘和迷信（鬼怪和地精），所以我想回答这个问题也不是一件简单的事情。请自行承担风险。

Answer 1

OAuth2.0是授权规范，但不是身份验证规范。RFC 6749，3.1。授权endpoint明确说明如下：

授权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之上的一个框架，第三方应用程序可以获取由服务管理的用户身份信息。

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

身份验证是确定最终用户主体（=唯一标识符）的过程。确定主题的方法有很多。ID

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

1. OAuth和OpenID Connect的完整Scratch实现者讨论了发现
2. 所有OAuth 2.0流的图表和电影
3. 所有OpenID连接流的图表
4. OAuth2.0的最简单指南