为我的产品实现了这样的功能,并分享了许多关注点和技术(特别是使用100％无状态REST后端的Backbone)我可以告诉你我对此有何看法,明确表示这不是是“答案”,而是一个对话的首发,可以从最终的讨论中学习,因为我认为我也有很多东西需要学习.

首先,我认为你应该100％无国籍. 100％,我的意思是100％:)不仅你的API层应该是无状态的,而是整个应用程序(当然除了客户端).在不同的层上移动会话(例如,redis)只是稍微改变了问题,但是没有解决它.一切(尤其是缩放比例)都会变得如此简单,以后您会对这个决定表示感谢.

所以,是的,您需要对每个请求进行身份验证.但这并不意味着您每次都必须点击身份验证提供程序.我学到的一件事是允许用户通过FB / GitHub / Whatever进行身份验证(从现在开始,远程服务)只是缓解注册/登录痛苦的一种手段,没有别的.您仍然需要扩展您的个人用户数据库.当然,每个用户都将与“远程”用户相关联,但在执行身份验证后不久,应用程序应该引用“您的”用户,而不是“远程”用户(例如GitHub用户).

履行

这是我实施的内容：

>我的API方法总是需要一个身份验证令牌. auth令牌是一个代表我系统用户的哈希,所以当我调用POST / api / board？name = [a_name]& auth = [my_token]时,我知道谁在调用,可以检查权限并且可以关联新创建的实体板给正确的用户.
>所述令牌与远程服务令牌无关.它们的计算逻辑特定于我的应用程序.但它映射了我的用户,也映射到远程用户,因此在需要时不会丢失任何信息.
>以下是我通过远程服务对用户进行身份验证的方法.我实现了服务文档中指定的远程身份验证.通常它是OAuth或OAuth,这意味着最终我得到一个代表远程用户的authToken.此令牌有两个目的：

>我可以使用它来调用充当用户的远程服务上的API方法
>我保证用户是它所说的人,至少通过远程服务的方式

>只要您的用户使用远程服务进行身份验证,您就可以在系统中加载或创建匹配的用户.如果系统中没有remote_id：GitHub_abc123的用户,则创建它,否则加载它.假设此用户具有id：MyApp_def456.您还创建了一个authToken,它具有您自己的逻辑,代表用户MyApp_def456并将其传递给客户端(cookie可以！)
>回到第1点:)

笔记

每次请求都会执行身份验证,这意味着您需要处理哈希和加密函数,这些函数的定义很慢.现在,如果你使用20次迭代的bcrypt,这将会杀死你的应用程序.我用它来存储用户登录时的密码,但是后来对authToken使用了一个不太重的算法(我个人使用的哈希值与SHA-256相当).这个令牌可以是短暂的(假设比破解它们的平均时间少)并且在服务器机器上相当容易计算.这里没有确切的答案.尝试不同的方法,衡量和决定.相反,我确信我更喜欢这类问题而不是会话问题.如果我需要计算更多哈希值或更快,我会增加cpu功率.使用会话和群集环境,您会遇到内存问题,负载平衡和粘性会话问题,或其他移动部分(redis).

显然,HTTPS是绝对必需的,因为authToken总是作为参数传递.