在这里，以略有不同的形式解决了这个问题：
RESTful身份验证
但这是从服务器端解决的。让我们从客户端看一下。但是，在此之前，有一个重要的前奏：
JavaScript加密无望
Matasano在这方面的文章很有名，但是其中包含的教训非常重要：
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
总结一下：
- 中间人攻击可以用以下方式轻松替换您的密码
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- 对于通过非SSL连接提供任何资源的页面，中间人攻击是微不足道的。
- 一旦有了SSL，您无论如何都会使用真实的加密货币。
并添加一个我自己的推论：
- 成功的XSS攻击可能导致攻击者即使在使用SSL的情况下，也可以在客户端的浏览器上执行代码-因此，即使您遇到各种麻烦，但如果攻击者找到了执行方法，浏览器加密仍然可能失败他人浏览器上的任何JavaScript代码。
如果您打算使用JavaScript客户端，这会使许多RESTful身份验证方案变得不可能或很愚蠢。我们看看吧！
HTTP基本认证
首先，是HTTP基本身份验证。最简单的方案：只需在每个请求中传递名称和密码。
当然，这绝对需要SSL，因为您将在每个请求中传递Base64（可逆）编码的名称和密码。任何在线路上监听的人都可以轻松提取用户名和密码。大多数“基本身份验证是不安全的”参数都来自“可怕的HTTP身份验证”。
该浏览器提供了内置的HTTP Basic Auth支持，但它很丑陋，您可能不应该在应用程序中使用它。但是，替代方法是将用户名和密码隐藏在JavaScript中。
这是最RESTful的解决方案。服务器不要求任何状态知识，并验证与用户的每个单独交互。一些REST爱好者（大多数是稻草人）坚持认为，保持任何一种状态都是异端，如果您想到其他任何身份验证方法，它们都会在您的嘴里泛滥。这种标准的遵从性在理论上有好处-即装即用的Apache支持-如果您愿意，可以将对象作为文件存储在受.htaccess文件保护的文件夹中！
有问题吗？您正在客户端缓存用户名和密码。这给了evil.ru一个更好的破解-甚至最基本的XSS漏洞都可能导致客户端将其用户名和密码发送到邪恶的服务器。您可以尝试通过对密码进行散列和加盐处理来减轻这种风险，但是请记住：JavaScript Crypto is Hopeless。您可以通过将其留给浏览器的基本身份验证支持来减轻这种风险，但是如前所述，这很丑陋。
HTTP摘要验证
使用jQuery可以进行摘要式身份验证吗？
更“安全”的身份验证，这是一个请求/响应哈希挑战。除了JavaScript Crypto是Hopeless之外，因此它只能在SSL上运行，并且您仍然必须在客户端缓存用户名和密码，这使其比HTTP Basic Auth更为复杂，但不再安全。
使用其他签名参数的查询身份验证。
另一个更“安全”的身份验证，您可以使用随机数和定时数据加密参数（以防止重复和定时攻击）并发送。最好的例子之一是OAuth 1.0协议，据我所知，这是在REST服务器上实现身份验证的一种非常糟糕的方式。
http://tools.ietf.org/html/rfc5849
哦，但是没有用于JavaScript的OAuth 1.0客户端。为什么？
记住，JavaScript加密是绝望的。没有SSL，JavaScript不能参与OAuth 1.0，并且您仍然必须在本地存储客户端的用户名和密码-这将其与Digest Auth放在同一类别中-它比HTTP Basic Auth复杂，但并不安全。
代币
用户发送用户名和密码，作为交换，用户将获得可用于验证请求的令牌。
这比HTTP Basic Auth稍微安全一些，因为一旦完成用户名/密码事务，您就可以丢弃敏感数据。由于令牌构成“状态”并使服务器实现更加复杂，因此它的RESTful也较少。
SSL静态
麻烦的是，您仍然必须发送该初始用户名和密码才能获得令牌。敏感信息仍然会触及您易受攻击的JavaScript。
为了保护用户的凭据，您仍然需要使攻击者远离JavaScript，并且仍需要通过网络发送用户名和密码。需要SSL。
代币到期
通常会执行令牌策略，例如“嘿，当此令牌的时间过长时，将其丢弃并让用户再次进行身份验证。” 或“我很确定可以使用此令牌的唯一IP地址是XXX.XXX.XXX.XXX”。这些政策很多都是不错的主意。
火警
但是，使用不带SSL的令牌仍然容易受到称为“ sidejacking”的攻击：http ://codebutler.github.io/firesheep/
攻击者无法获取您用户的凭据，但是他们仍然可以假装成为您的用户，这很糟糕。
tl; dr：通过网络发送未加密的令牌意味着攻击者可以轻松地获取这些令牌并假装成为您的用户。FireSheep是一个使此操作非常简单的程序。
一个单独的，更安全的区域
您正在运行的应用程序越大，绝对难以确保它们将无法注入某些更改您处理敏感数据的方式的代码就越难。您完全相信您的CDN吗？您的广告商？您自己的代码库？
信用卡详细信息通用，用户名和密码通用-一些实施者将“敏感数据输入”与他们的应用程序其余部分保持在单独的页面上，该页面可以被严格控制和锁定，最好是一个页面。很难用网络钓鱼用户。
Cookie（仅表示令牌）
可以（并且很常见）将身份验证令牌放入cookie。这不会使用令牌更改auth的任何属性，这更方便了。前面所有的论点仍然适用。
会话（仍仅表示令牌）
会话身份验证只是令牌身份验证，但有一些区别，使它看起来似乎有点不同：
- 用户以未经身份验证的令牌开头。
- 后端维护一个与用户令牌绑定的“状态”对象。
- 令牌在cookie中提供。
- 应用程序环境将细节从您那里抽象出来。
除此之外，实际上，它与令牌认证没有什么不同。
这从RESTful实现中走得更远-使用状态对象，您将在有状态服务器上的普通RPC路径上走得越来越远。
OAuth 2.0
OAuth 2.0解决了“软件A如何赋予软件B访问用户X的数据而软件B无法访问用户X的登录证书的问题”。
对于用户来说，该实现方式只是一种标准的方式，然后让第三方服务去“是的，该用户和此令牌匹配，您现在就可以从我们这里获取他们的一些数据”。
不过，从根本上讲，OAuth 2.0只是一个令牌协议。它具有与其他令牌协议相同的属性-您仍然需要SSL保护这些令牌-只是改变了这些令牌的生成方式。
OAuth 2.0可以通过两种方式为您提供帮助：
- 向他人提供身份验证/信息
- 从他人那里获取身份验证/信息
但是，归根结底，您只是在使用令牌。
回到您的问题
因此，您要问的问题是“我应该将令牌存储在cookie中，让环境的自动会话管理来处理这些详细信息，还是应该将令牌存储在Javascript中并自己处理这些详细信息？”
答案是：做任何让自己快乐的事情。
但是，关于自动会话管理的事情是，幕后发生了许多不可思议的事情。通常，自己控制这些细节会更好。
我21岁，所以SSL是
另一个答案是：对所有内容都使用https，否则盗版者将窃取用户的密码和令牌。