我想实现一个 OAuth2 服务器（技术并不重要）。我对一种方法有疑问：
假设我有一个提供 access_tokens 和 refresh_tokens 的 OAuth2 服务器。我的用户将通过 Google 和 Facebook 等 OAuth2 提供商登录。当外部提供商向我的应用程序发出 OK 信号时，我想存储用户名和电子邮件。之后，我的应用程序知道用户并且我的服务器提供了 access_token 和 refresh_token。这实际上给了我的应用程序两个角色：
这是否符合RFC 6749 spec？据我了解，OAuth2 服务器也可以访问用户的密码和用户名，但我不喜欢存储有关用户的敏感信息。或者这是一种常见的方法？
【问题讨论】：
狭义的OAuth服务器是授权的服务器。从广义上讲，人们在提到 OAuth 服务器时，会不自觉地期待以下三个角色。
使用外部提供商（例如 Google 和 Facebook）登录意味着您将身份验证委托给外部提供商。请注意，RFC 6749 表示资源所有者（= 最终用户）的身份验证超出了范围（请参阅3.1. Authorization Endpoint）。
基于访问令牌提供访问被归类为资源管理。应该参考RFC 6750 而不是 RFC 6749。资源管理也超出了 RFC 6749 的范围。
但是，作为外部服务器的 OAuth 2.0 客户端，对于您的服务器的客户端应用程序没有任何特殊意义。
因此，使用外部提供程序并不一定意味着您的服务器是 OAuth 服务器。换句话说，在外部服务器执行最终用户身份验证后，您的服务器可能会随心所欲地运行，而无需关心 RFC 6749。
让人们感到困惑的是一些使用外部 OAuth 服务器进行“身份验证”（而不是“授权”）的解决方案。例如OmniAuth 和Auth0。身份验证超出了 RFC 6749 的范围，但authorization endpoint 的流程将最终用户身份验证作为一个步骤。诸如 OmniAuth 之类的解决方案将身份验证步骤用于不同的目的。但是，出于“身份验证”的目的，应该使用OpenID Connect。
如果您不喜欢存储有关用户的敏感信息，使用外部 OpenID 提供程序是一种方法。 Google、Facebook 等大牌现在都在 OpenID Connect 服务器上。请注意，OpenID Connect 服务器同时是 OAuth 2.0 服务器，因此您可以将其用作 OAuth 2.0 服务器。 Stormpath 也值得一试。它提供“用户管理 API”。
如果您愿意，也可以将 (a) 访问/刷新令牌、(b) 客户端应用程序的元数据和 (c) 服务的元数据的管理委托给外部纯“授权”服务器。 Authlete 就是一个例子。从实施者的角度来看，Authlete Defenitive Guide 和 blog 包含有关 OAuth 2.0 和 OpenID Connect 的详细通用信息。
【讨论】：