我的应用程序架构如下：我有一个Web服务（在GAE上运行，与此问题无关），该服务包含的数据可通过网站以及移动和桌面应用程序获得。
目前，用户通过Google ClientLogin对网站进行身份验证，并且应用通过GAE内置的oauth提供商进行身份验证/获得授权。 （此处主要使用OAuth进行身份验证，我的应用实际上并未通过OAuth使用任何外部数据，而不是用户的唯一ID和电子邮件地址。）
我想做的是扩展用户可以用来登录的服务数量。由于应用程序的复杂因素，我似乎需要OAuth。但我无法正确地概念化这种流程应该如何发展。
让我们以Facebook为例。当移动应用程序通过Facebook oauth流并获取访问令牌时，这还不够 - 因为我的服务，而不是应用程序，实际上需要与Facebook交谈以检索联系信息和唯一用户ID。这使我认为OAuth流程需要在我的服务环境中发生，而不是移动应用程序。我的服务然后成为消费者，Facebook成为oauth提供者，并且服务保留在oauth访问令牌上，当用户第一次设置他们的帐户时会发生这种情况。
如果这是正确的方法，那么应该在哪里为应用程序提供身份验证？当用户已拥有帐户并安装移动应用程序的新实例时会发生什么？我想也会经历oauth过程，将凭证与我服务已存储的数据进行匹配，然后从服务向应用程序发出我自己的“访问令牌”，以授权该应用程序的实例。这似乎令人费解和苛刻。
我确信我不能成为唯一一个为后端移动应用程序“借用”第三方帐户系统的人，但我真的看不出正确的做法是什么这是。
我没有看到和/或在概念上出错了什么？
答案 0 :(得分：10)
一些同事和我曾经做过一个非常相似的项目，回到大学。我们使用各自的OAuth API通过Facebook或Foursquare对用户进行身份验证。
该应用的原生Android版本通过OAuth提供商的起始页面打开了WebView，该页面在身份验证后重定向回我们的服务。然后我们的服务从OAuth提供商处请求了OAuth令牌（Foursquare有一些pretty simple instructions）。当我们获得该令牌时，我们使用cookie设置会话，我们可以从应用程序访问。
为了验证会话，我们只是检查了访问令牌是否仍然对提供者有效。我们还使用各自提供商的唯一用户ID来区分用户。
所以，是的，对我们有用的是：让应用程序进行身份验证＆amp;授权您的服务，而不是应用程序本身。