这是一个更普遍的问题，但我希望它对SO仍然有效。
到目前为止，我已经了解到，一般来说，移动应用程序（例如官方Pinterest应用程序）使用密码凭据流让其用户直接登录和访问API。 （我们假设他们为此使用了OAuth）
因此，他们收集用户名和密码，将其发送到他们的服务器并获得一个用于后续请求的令牌。
现在用户不想使用例如注册和创建帐户Facebook作为授权服务器。所以我的问题是：
如何实施此流程？
我有根据的猜测：
这是对的吗？
答案 0 :(得分：3)
首先，应用不应使用密码凭据授予。 specification对此非常清楚：
在传统的客户端 - 服务器身份验证模型中，客户端 请求访问受限资源（受保护资源） 服务器通过使用资源所有者的服务器进行身份验证 证书。为了提供第三方应用程序访问权限 受限资源，资源所有者与其共享其凭据 第三方。这会产生一些问题和限制
然后规范继续描述这些问题。
关于资源所有者密码凭证授权：
授权服务器在启用此授权类型时应特别小心，并且仅在其他流不可行时才允许。
OAuth 2.0的全部目的，我不必使用密码凭据授权等用户将密码移交给应用程序。
关于您的第二个问题：当用户不想在您的应用中注册和创建帐户，但想要使用例如Facebook进行身份验证？
请记住，隐式授权和授权代码授予都可以通过使用浏览器控件来验证用户。在与授权服务器的浏览器会话中，您可以以任何方式自由地对用户进行身份验证。当然，您可以使用自己的用户/密码数据库，但也可以使用其他机制，例如WS-Federation。在您的情况下，听起来好像用户想要使用Facebook进行身份验证。
使用Facebook进行身份验证不是由您的客户端应用程序完成的，而是由您的授权服务器完成的。它通常使用Facebook授权代码授予，然后调用读取用户的个人资料以获取其Facebook用户ID，名称等。
如果您不想自己构建此类授权服务器，则可以使用现有服务器。有几家公司提供登录即服务解决方案，包括the one I work for。
更新：您在下面的评论中询问了几个跟进问题。我将在这里简要回答一下：
首先，一些使用OAuth保护其服务的公司允许使用密码凭据授予，这并不意味着您应该这样做。事实上，可能存在更多不提供这种可能性的公司的例子。
与设备应用共享密码存在真正的信任问题和真正的安全风险。首先，设备上的应用程序比服务器更容易破解。此外，如果您为应用程序提供密码，大概该应用程序还需要将其存储在某个地方以备将来使用。作为用户，我只是希望该存储是安全的，可能是我的机器上运行的恶意软件。有关更多问题，请参阅上面提到的OAuth 2.0规范中的介绍。
其次，所有优秀的授权服务器都区分第一方客户端和第三方客户端。像您这样的第一方客户由控制授权服务器的同一家公司控制，对于这样的应用，授权服务器不会要求用户共享数据的权限，因为谈论与您自己共享数据是没有意义的。这就是为什么这些公司的网站不会询问您是否允许他们代表您共享他们所持有的数据。他们已经拥有它，并且没有“分享”。
当然，您可能会争辩说，您从未见过这些公司中任何一家谈论第一方客户与第三方客户之间的区别。但他们不这样做的原因应该是显而易见的：当你处理它们时，你总是第三方应用程序。他们不需要告诉你他们对待自己的方式不同。
我在您的场景中选择的机制取决于客户端应用程序的性质以及它访问的服务的性质。你有什么要求？
无论如何，如果运行应用程序的设备具有安全的存储设施，例如Windows Phone 8.1，我可能会考虑在没有客户端凭据的情况下使用授权代码授权。这样，用户就不必再次登录。如果我们谈论的是网站或SPA，我会考虑隐式授权（授权服务器提供的“记住我”功能，如果有的话）。同样，规范给出了几种方案的每种授权类型的优缺点。