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