HTTP基本/摘要和复杂系统（例如oauth / aws auth）对我不感兴趣。
我想提出一些断言，看看它们是否存在是正确的。
在移动应用程序中只能使用身份验证令牌，而无需会话。在浏览器上下文中，您需要Cookie才能在客户端保留令牌。但这也意味着令牌以及与令牌有关的所有事物也必须由服务器保留和处理。
令牌可以在服务器端被吊销。 Cookies没有该选项，并且将会/应该过期。
仅使用Cookies意味着sessionId与用户帐户相关，并且不受任何限制。远远超出了预期，感谢您的帮助！
#1 楼
在基于会话的身份验证中，服务器负责服务器端的所有繁重工作。从广义上讲，客户端使用其凭据进行身份验证，并接收
session_id（可以存储在cookie中）并将其附加到每个后续的发出请求中。因此，这可以看作是“令牌”，因为它等效于一组凭据。但是，此session_id字符串没有任何花哨的地方。它只是一个标识符，服务器将执行其他所有操作。它是有状态的。它将标识符与用户帐户相关联（例如，在内存或数据库中）。它可以将此会话限制或限制为特定操作或特定时间段，如果存在安全隐患，可以使其无效。更重要的是，它可以做到并即时改变所有这些。此外，它可以记录用户在网站上的一举一动。可能的缺点是可伸缩性差（尤其是超过一个服务器场）和大量的内存使用。初始步骤相同。凭证与令牌交换凭证，凭证随后附加到每个后续请求（也可以存储在cookie中）。但是，出于减少内存使用，易于扩展和总体灵活性（令牌可以与另一个客户端交换）的目的，发出了一个带有所有必要信息的字符串（令牌），该字符串在客户端向客户端提出的每个请求之后进行检查服务器。有多种使用/创建令牌的方法：使用哈希机制，例如HMAC-SHA1
token = user_id|expiry_date|HMAC(user_id|expiry_date, k)
其中
user_id和expiry_date以明文形式发送，并附带生成的哈希值（k仅对服务器是已知的）。 > 对称地加密令牌，例如使用AES
token = AES(user_id|expiry_date, x)
其中
x代表加密/解密密钥。非对称加密，例如使用RSA
token = RSA(user_id|expiry_date, private key)
生产系统通常比这两种原型更为复杂。例如，亚马逊在其网站上同时使用了两种机制。混合也可以用来发布令牌，如第2节所述，并且还可以将用户会话与其关联以进行用户跟踪或可能的撤销，并且仍然保留经典令牌的客户端灵活性。此外，OAuth 2.0还使用短期和特定的承载令牌以及较长的刷新令牌，例如以获得承载令牌。
来源：
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-图书馆/
https://stackoverflow.com/questions/1283594/securing-cookie-based-authentication
https://web.archive.org/web/20170913233103/https://auth0.com / blog / angularjs-authentication-with-cookies-vs-token /
解密Web身份验证（无状态会话Cookies）
https://scotch.io/tutorials/the-ins-and-outs-of基于令牌的身份验证
评论
如果在CBC模式下使用b），请注意字节翻转攻击。 resources.infosecinstitute.com/…您可能需要先进行HMAC加密，才能检测到更改。
–r00t
2015年6月21日14:59
您必须使用经过身份验证的加密（AEAD或加密和MAC），而不仅仅是加密。如果不使用AEAD，则必须在加密之后进行身份验证，并且必须在解密之前检查身份验证。这不是可选的，没有身份验证的加密是没有用的。
– Z.T.
15年7月20日在13:36
您能否进一步说明为什么将基于会话的身份验证视为有状态的？
– fujy
16年11月18日在13:04
换句话说，服务器试图在此处维护的状态是什么？
– fujy
16年11月18日在13:09
@fujy在基于会话的身份验证中，服务器正在维护客户端的登录状态：他/她/它是否已登录？多少时间？该信息由会话ID索引，但由服务器存储在数据库，文件系统或内存中。它不存储在id本身上。
–索尼·桑托斯（Sony Santos）
17 Mar 8 '17在2:31
#2 楼
HTTP是无状态的，并且为了具有经过身份验证的状态，您需要某种用于参考有关用户信息的令牌。此会话ID通常采用以Cookie值形式发送的随机令牌形式。 OAuth访问令牌用于标识用户以及该用户有权访问的资源。在使用OAuth单点登录的应用程序中，通常会用OAuth访问令牌交换会话ID，该会话ID可以跟踪各种各样的用户状态。从攻击者的角度来看，劫持会话ID或OAuth访问令牌与用户名和密码一样好，有时甚至更好。会话ID必须具有安全性，可以保护用户帐户免遭侵害。
从开发人员的角度来看，切勿重蹈覆辙。使用平台提供的会话管理器，并确保其配置符合OWASP会话管理指南。
评论
我什至认为，劫持会话ID比获取用户名和密码更糟糕，因为它绕过了许多安全措施，例如两因素身份验证。
– davis_m
15年2月16日在16:15
@davis_m好点，已更新。
–rook
15年2月16日在16:33
感谢您的输入，但我对没有繁琐的OAuth机制的令牌身份验证更感兴趣。这些文章暗示这已经完成，我只想获取更多信息：auth0.com/blog/2014/01/07/…django-rest-framework.org/api-guide/authentication/…
–骗局
2015年2月16日在21:23
@Hoax是一个单独的问题。 OAuth流程真的很有用。
–rook
15年2月16日在23:51
请注意，ASP.NET违反了OWASP准则：Web服务器不存储有效和过期的身份验证票证，以供以后比较。如果恶意用户获得有效的表单身份验证cookie，这会使您的站点容易受到重播攻击-这意味着，如果用户注销，它所做的就是删除cookie客户端。我会重新发明轮子的这一部分。
– SilverlightFox
15年2月18日在11:47
#3 楼
因此，在基于会话的身份验证上，要提高访问资源的安全性，该资源是必需的：它应替代用户的凭据
始终使用永久性cookie
应标识回访网站的用户
应使用2要素身份验证
评论
我不确定您对＃3的理解是否正确。 Web服务器/应用程序可以从其会话值可以与用户身份无关的意义上撤消cookie。浏览器可能会继续在请求中显示它，但服务器不会将其用作身份证明。如果我误解了您的意思，请您澄清一下吗？