OAuth2实现方法

Question

我想实现OAuth2服务器（技术并不重要）。我对方法有疑问：

假设我有一个提供access_tokens和refresh_tokens的OAuth2服务器。我的用户将通过Google和Facebook等OAuth2提供商登录。当外部提供商向我的应用程序提供OK标志时，我想存储用户名和电子邮件。之后，我的应用程序知道用户，我的服务器提供access_token和refresh_token。这给我的应用程序实际上有两个角色：

• OAuth2服务器（存储用户信息并根据上述令牌提供访问权限）。
• OAuth2客户端（基于外部提供商获取授权）。

这符合RFC 6749 spec吗？根据我的理解，OAuth2服务器也可以访问用户的密码和用户名，但我不想存储有关用户的敏感信息。或者这是一种常见的方法吗？

Answer 1

从狭义上讲，OAuth服务器是授权的服务器。从广义上讲，人们在引用OAuth服务器时会无意识地期望以下三种角色。

1. 的验证
2. 的授权
3. 资源管理

使用外部提供商（例如Google和Facebook）进行登录意味着您将身份验证委派给外部提供商。请注意，RFC 6749表示资源所有者（=最终用户）的身份验证超出了范围（请参阅3.1. Authorization Endpoint）。

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

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

因此，使用外部提供程序并不一定意味着您的服务器是OAuth服务器。换句话说，在外部服务器执行最终用户身份验证后，您的服务器可能会按照自己的喜好行事，而无需关心RFC 6749。

使人们感到困惑的是使用外部OAuth服务器进行身份验证的一些解决方案。 （不是＆＃34;授权＆＃34;）。例如OmniAuth和Auth0。身份验证超出了RFC 6749的范围，但authorization endpoint的流程包括最终用户身份验证作为一个步骤。 OmniAuth等解决方案将身份验证步骤用于不同目的。但是，出于＆＃34;身份验证＆＃34;的目的，应使用OpenID Connect。

如果您不想存储有关用户的敏感信息，则使用外部OpenID提供程序是一种方法。谷歌，Facebook和其他大牌现在都是OpenID Connect服务器。请注意，OpenID Connect服务器同时是OAuth 2.0服务器，因此您可以将其用作OAuth 2.0服务器。 Stormpath也值得一试。它提供了＃34;用户管理API＆＃34;。

如果您愿意，还可以将（a）访问/刷新令牌，（b）客户端应用程序的元数据和（c）您的服务元数据的管理委派给外部纯粹的授权＆＃34 ;服务器。 Authlete就是一个例子。从实施者的角度来看，Authlete Defenitive Guide和blog包含有关OAuth 2.0和OpenID Connect的详细通用信息。