我目前正在为新项目规划基础架构,并为Web和移动应用程序提供通用后端.移动应用程序通常由令牌授权,而不是cookie,但我想知道为什么？我没有想到设置和预加长基于cookie的身份验证的灵活性,但我想知道令牌背后的真正论点. 最佳答案 我对
JSON web tokens有一些经验.所以我写下这些.

原因1：

一个问题是应用程序可伸缩性.当你使用cookie时,它通常是这样的：

>用户登录.Cookie随附会话ID.会话ID保留在后端的共享会话存储中. Cookie存储在浏览器中.
>每次请求都会显示Cookie.后端从cookie中获取会话ID,并在会话ID已知时检查某种数据库.

所以基本上你有这个在每个请求上查找会话ID的开销.现在,这意味着所有后端服务器都必须知道会话ID – 它们共享某种资源来查找会话ID.另一种方法是提出一些聪明的请求路由,以便每个用户都能访问经过身份验证的固定服务器.所以我不能轻易引入新的服务器.

另一方面,像JSON Web令牌这样的令牌只是一个密码保护的声明,一个是经过身份验证的(可能是关于用户的其他声明).它是这样的：

>用户登录.发行令牌,证明用户已经过身份验证的声明(可选用户信息).令牌由发行者以加密方式签名.
>每个请求都会显示令牌.在签名时,我们可以检测令牌是否有效且未经更改.我们也可以说谁发出了令牌.

现在,由于每个服务器都可以通过加密方式证明令牌是由受信任方(在大多数情况下是我们的后端服务器)发出的,因此后端服务器确保用户已通过身份验证.但是,您不再需要该共享会话存储.所以,例如根本没有关系请求的服务器.这增强了可伸缩性并使操作更容易一些.

原因2：
Cookie的大小限制为4KB.令牌的大小不受限制,因此它可以传输更多信息(当然,令牌应该很小).

原因3：
从理论上讲,您可以在Web应用程序中控制何时发送令牌.对于任何匿名资源都没有必要.每个请求都会发送一个cookie.

原因4：
为一个域发布cookie.如果您访问另一个域,那么您遇到了麻烦.另一方面,令牌可以发送到任何域.

缺点1：
但是,没有免费的午餐. Cookie可以通过HttpOnly标志进行保护,因此无法在Javascript中访问它.这使得XSS很难(呃).另一方面,令牌无法实现这一点.