OAuth授权与身份验证

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

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

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

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

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

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

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

OAuth身份验证？

---

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

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

OpenID连接 OpenID1.0和OpenID2.0是旧的身份验证规范。制定规范的人希望人们使用OpenID进行身份验证。然而，一些人开始使用OAuth 2.0进行身份验证（而不是授权），OAuth身份验证迅速盛行

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

是的，这让人们更加困惑

OAuth 2.0和OpenID Connect的一句话定义 是一个框架，在该框架中，服务用户可以允许第三方应用程序访问其托管在服务中的数据，而无需向应用程序透露其凭据（ID和密码）

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

（对不起，这些定义摘自我的公司页面）

从实现者的角度定义 身份验证是确定最终用户的主题（=唯一标识符）的过程。确定主题的方法有很多。ID和密码、指纹、虹膜识别等

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

另见

---

我还发现这些答案很有用：OAuth2.0是一个安全协议。详细信息：对于那些想知道为什么基于OAuth的身份验证不够安全的人，我假设。“授权流包含身份验证作为其第一步。这是人们经常感到困惑的原因。”Gold。我可以看到两个图表之间的唯一区别是第一个包含“用户数据”，第二个包含“用户身份”，所以是的，这是令人困惑的。