2013-03-26 44 views
4

我正在移动应用程序的后端工作,使用ASP.NET MVC 4 Web Api构建RESTful API。该应用将在iOS和Android上运行。我的用户将只能使用他们的Facebook帐户登录,并且只有在登录后才能使用整个功能。移动应用程序的REST API上的OAuth

我对移动应用程序没有太多经验,这更多的是设计问题:哪两种方案(或者第三种方案?)对于您来说似乎更适合谁来负责Facebook身份验证:

  1. 移动客户端负责。在不访问后端的情况下,它直接与Facebook对话,允许用户输入他的凭证,当它从Facebook获得令牌时,它会首次点击后端,并在每个请求中将令牌传递给后端。
  2. 后端API负责。移动客户端尝试从中访问资源。后端从客户端获取认证令牌,因此它重定向到Facebook登录。用户输入凭证并将Facebook回复回到传递令牌的后端。然后,后端愿意回答客户对所需资源的回应。

当然,第二个方案是指后端应该使用包像DotNetOpenAuth处理OAuth的,而在第一个场景中,这一切发生在移动客户端。

+0

伟大的问题@ zafeiris.m。你最终使用了什么?你学到了什么? – 2015-05-15 06:00:49

回答

1

我认为第一种方法更为正确,因为它更好地模拟了http的无状态特性(它相当于传统的http身份验证方法,如Basic Auth)。每次通话时,您都会将Facebook OAuth令牌发送到网络API。否则,服务器需要使用像Cookie这样的机制以某种方式保持已认证的用户的状态,这首先看起来不正确。我只会在服务器需要使用需要身份验证的其他服务时使用服务器端身份验证,但在这里看起来像您的情况。

+1

好吧,在这两种情况下,我都记得客户端应该总是在请求中包含令牌。问题是,不包含令牌应该产生认证挑战(场景2)还是移动应用程序甚至不需要首先获取令牌就调用后端(场景1)。 – 2013-03-27 21:33:40