有很多文章，为什么 OAuth 不用于身份验证。我不明白，身份验证发生在哪里（如果使用不正确）。有人可以以错误的方式解释 OAuth 的简单可信网络应用和 SPA 使用吗？
如果我将从应用程序 /users/1/detail 调用并传递正确的 Bearer 标头，那么 OAuth 是如何用于验证用户是否真的是 id 1？是否需要使用 JWT 才能解码访问令牌并与内部包含的 id 进行比较？
【问题讨论】：
标签： authentication oauth oauth-2.0
假设有一个类似 OAuth 的协议（我们称之为 MyAuth），但用于通过应用的后端对应用的前端进行身份验证。
要了解 OAuth 和 MyAuth 不同的原因，首先要知道它们都有长期存在的刷新令牌和短期访问令牌。此外，如果party1 需要访问party2，则party2 必须生成这些令牌，而party1 必须以某种方式存储这两个令牌以保持访问权限。
关于 OAuth：
我们有三方（也有其他类型）：App1 的后端、App1 的前端和 App2 的后端。
这里的目的是代表用户授予对 App1 的后端和前端的访问权限，以及对 App2 的后端的访问权限。
仅在此处，App1 的后端和 App2 的后端可以被信任为安全方。
关于 MyAuth：
我们有两方：App1 的后端，App1 的前端。
这里的目的是让 App1 的前端，代表用户访问 App1 的后端（这是所有应用程序的情况，在用户登录应用程序后）。
这里只有 App1 的后端是可信方。
由于刷新令牌的寿命很长，因此未经授权访问它们可能是一个严重的问题。因此，在 OAuth 流程中，它被设计为 App2 后端的刷新令牌仅存储在 App1 的后端（即受信任方）。并且只有 App2 后端的访问令牌（它是短暂的）被发送到 App1 的前端。在 MyAuth 中，我们没有可信方来存储 App1 后端的刷新令牌。这意味着，您将刷新令牌存储在相对容易被盗的地方 - 这是一个安全问题。因此，虽然 OAuth 不必这样解决这个问题，但 MyAuth 可以。
要了解有关会话安全和各种类型的流的更多信息，请参阅：https://hackernoon.com/all-you-need-to-know-about-user-session-security-ee5245e6bdad
【讨论】：
OAuth 2.0 is NOT an Authentication protocol。 （但您可以像 OpenID Connect 一样在 OAuth 2.0 之上构建一个）
OAuth 是一种开放标准、可扩展的 RESTful 协议，用于使用 HTTP 对服务器资源进行委派授权。
【讨论】：