OAuth2实现方法

Question

我想实现一个OAuth2服务器(技术并不重要)。关于一种方法，我有一个问题：

假设我有一个OAuth2服务器，它提供access_tokens和refresh_tokens。我的用户将通过谷歌和Facebook这样的OAuth2提供商登录。当外部提供者给我的应用程序一个OK签名时，我想存储用户名和电子邮件。之后，我的应用程序就知道了用户，我的服务器提供了一个access_token和一个refresh_token。这给了我的应用程序两个角色：

• OAuth2服务器(存储用户信息并提供基于上述令牌的访问)。
• OAuth2客户端(基于外部提供程序获得授权)。

这是否符合RFC 6749规范？据我所知，OAuth2服务器还可以访问用户的密码和用户名，但我不喜欢存储有关用户的敏感信息。还是说这是一种常见的方法？

Answer 1

从狭义上讲，authorization.服务器就是OAuth服务器。从广义上讲，人们在引用OAuth服务器时不自觉地期望有以下三个角色。

1. Authentication
2. 授权
3. 资源管理

使用外部提供程序(如Google和Facebook)登录意味着将authentication委托给外部提供程序。请注意，RFC 6749说资源所有者(=终端用户)的身份验证超出了范围(参见3.1。授权端点)。

提供基于访问令牌的访问被归类为资源管理。应该引用RFC 6750而不是RFC 6749。资源管理也超出了RFC 6749的范围。

但是，作为外部服务器的OAuth 2.0客户端，对服务器的客户端应用程序没有任何特殊意义。

因此，使用外部提供程序并不一定意味着您的服务器是OAuth服务器。换句话说，在外部服务器执行最终用户身份验证之后，您的服务器可以随意运行，而不关心RFC 6749。

让人困惑的是一些使用外部OAuth服务器进行“身份验证”(而不是“授权”)的解决方案。例如OmniAuth和Auth0。身份验证超出了RFC 6749的范围，但授权端点中的流作为步骤包括最终用户身份验证。OmniAuth等解决方案将身份验证步骤用于不同的目的。但是，为了“身份验证”的目的，应该使用OpenID连接。

如果您不喜欢存储有关用户的敏感信息，则使用外部OpenID提供程序是一种方法。谷歌、Facebook和其他大公司现在都是OpenID连接服务器。请注意，OpenID连接服务器同时也是OAuth 2.0服务器，因此可以将其用作OAuth 2.0服务器。风暴路径也值得一查。它提供了“用户管理API”。

如果需要，还可以将(a)访问/刷新令牌、(b)客户端应用程序的元数据和(c)服务的元数据委托给外部纯“授权”服务器。授权人就是一个例子。授权人辩护指南和博客从实现者的角度包含关于OAuth 2.0和OpenID连接的详细一般信息。