Authentication 使用OAuth和/或OpenID开发RESTful API

我正在绞尽脑汁用多个外部令牌提供者实现OAuth或OpenID。从我的角度来看，像谷歌这样的提供商在一个api中混合了这两种规范，我在保护资源和处理用户数据的方式上区分了这两种机制。OpenID仅用于身份验证，我自己生成访问令牌并保存所有用户数据，而另一方面OAuth提供外部访问令牌并管理用户数据

所涉实体：

外部提供程序-这是我对OAuth/OpenID提供程序（如Google OAuth）的称呼

后端-主要用作客户端RESTful API的服务器

客户端-需要访问后端提供的资源的应用程序（如SPA、IOS应用程序、桌面客户端）

我正在为几种不同类型的客户端开发一个快速后端（RESTAPI），包括web、ios/android。据我所知，我有以下几种选择：（参考我想使用的提供者的大多数实现文档，而不是规范）

选项1-OpenID

客户端通过与任何外部提供商（苹果、谷歌、Facebook）登录来获取身份验证码

客户端将此身份验证代码发送到我的后端，该代码用于颁发id_令牌

后端使用此id_令牌对用户进行身份验证，并存储有关用户的任何必需信息

后端生成用于授权的访问/刷新令牌，并将其发送回客户端

现在我可以使用我的访问令牌进行授权，使用刷新令牌进行身份验证状态管理（注销、使令牌失效）

问题-真的有问题吗

• 我不确定是否需要经常检查用户是否仍然是有效身份。对于有效标识，我的意思是外部标识（例如google用户）是否仍然存在，这基本上与我的持久层是否必须使该用户无效（删除）有关。换句话说，我必须将我的持久层与外部提供者同步，以避免死/不可用的身份。如果电子邮件地址等信息发生更改，而我的后端没有收到通知，则这一问题尤其严重。或者我应该接受这样一个事实，即我的后端中的用户只是通过id与外部用户相关，客户端必须自己管理其后端中的数据（例如，在客户端更改其电子邮件）。这意味着我更愿意忽略（在提供者）对外部用户数据的任何更改

选项2-OAuth

客户端通过与任何外部提供商（SiwA（ios）、谷歌、Facebook）登录来获取身份验证码

客户端将此身份验证代码发送到我的后端，该代码用于从提供程序发出访问令牌/刷新令牌

后端发回从外部提供程序获得的访问令牌/刷新令牌

现在，每次客户端发出请求时，它都必须包含外部访问令牌，然后在后端使用该令牌询问外部提供者该令牌是否有效，并且客户端是否有权访问ressource。换句话说，我使用外部访问令牌进行授权

每次在后端需要用户数据（例如电子邮件、地址…）时，都需要通过提供客户端提供的访问令牌向外部提供商请求此数据

问题:

• 我假设刷新过程必须在客户端执行，以防令牌过期时后端重定向未经授权的提供者。对吗
• 如何确定令牌来自哪个提供程序。对我来说，实现一个试错过程并询问每个提供者这是否是一个有效的令牌似乎很奇怪。例如，如果后端接收到请求头中的访问令牌，它不知道该询问哪个提供者。（或者我应该像

  承载提供者令牌

  那样在报头中编码此信息，以便知道在哪里检查访问令牌
• 使用选项2，外部提供程序遇到停机时，任何用户都无法使用我的后端，而使用选项1时，只有登录（初始登录或显式注销后，刷新令牌无效）不可用于此特定提供程序

有什么我遗漏的吗？在我看来，选项2向身份验证提供商引入了许多不必要的通信，而选项1忽略了可能需要的任何通信（例如身份状态同步）？

---

我的主要问题是，考虑到似乎更适合我的场景的选项1，我是否必须对用户状态的任何状态更改做出反应，如外部提供商的电子邮件更改，或者忽略外部用户id以允许身份验证有任何缺点。

修正OpenID，意识到我只需要身份验证，不需要授权，也不需要用户数据的严格耦合。在提出问题时，我意识到了区别，但是我没有深入挖掘我的项目的需求。因此，我放弃了基本的OAuth协议，因为我不需要对外部数据进行任何授权rces

关于OpenID，来自OpenID提供商的外部身份管理不在协议范围内，必须独立完成。还有其他协议和方法处理此问题，例如

我最终依赖于id_令牌提供的外部id是唯一的这一事实，并在第一次身份验证（基本上是注册）时初始化一次性映射。我的服务器从此开始管理用户数据。后续的身份验证请求依赖于以下事实：