基于 cookie 的身份验证如何工作？答案

【问题标题】：How does cookie based authentication work?基于 cookie 的身份验证如何工作？
【发布时间】：2013-07-20 02:12:44
【问题描述】：

谁能一步一步地描述基于 cookie 的身份验证是如何工作的？我从来没有做过任何涉及身份验证或 cookie 的事情。浏览器需要做什么？服务器需要做什么？以什么顺序？我们如何确保安全？

我一直在阅读有关不同类型的身份验证和 cookie 的信息，但我想要一个关于如何一起使用这两者的基本描述 - 我只读到它们经常一起使用，但找不到关于如何使用的描述.

【问题讨论】：

howstuffworks.com/cookie.htm

【解决方案1】：

cookie 基本上只是字典中的一个项目。每个项目都有一个键和一个值。对于身份验证，密钥可能是“用户名”，值是用户名。每次您向网站发出请求时，您的浏览器都会在请求中包含 cookie，主机服务器将检查 cookie。所以认证可以像这样自动完成。

要设置 cookie，您只需将其添加到服务器在请求后发回的响应中。浏览器将在收到响应后添加 cookie。

您可以为 cookie 服务器端配置不同的选项，例如过期时间或加密。加密的 cookie 通常称为签名 cookie。基本上服务器对字典项中的键和值进行加密，因此只有服务器可以使用这些信息。那么cookie是安全的。

浏览器将保存服务器设置的 cookie。在浏览器向该服务器发出的每个请求的 HTTP 标头中，它将添加 cookie。它只会为设置它们的域添加 cookie。 Example.com 可以设置 cookie 并在 HTTP 标头中添加选项，以便浏览器将 cookie 发送回子域，例如 sub.example.com。浏览器向不同的域发送 cookie 是不可接受的。

【讨论】：

我的理解是浏览器能够将 cookie 发送回同一个域。与此相关，浏览器在区分两个域时是否考虑子域？
您可以在 HTTP 标头中设置浏览器如何处理子域的选项。
你有这方面的教程吗？

【解决方案2】：

我意识到这已经晚了好几年，但我想我可以扩展 Conor 的答案并在讨论中添加更多内容。

谁能一步一步地描述基于 cookie 的身份验证是如何工作的？我从来没有做过任何涉及身份验证或 cookie 的事情。浏览器需要做什么？服务器需要做什么？以什么顺序？我们如何确保安全？

第 1 步：客户 > 注册

首先，用户必须注册。客户端向服务器发送一个 HTTP 请求，其中包含他/她的用户名和密码。

第 2 步：服务器 > 处理注册

服务器收到此请求并在将用户名和密码存储到数据库之前对密码进行哈希处理。这样，如果有人获得了对您数据库的访问权限，他们将看不到您用户的实际密码。

第 3 步：客户端 > 用户登录

现在您的用户登录。他/她提供他们的用户名/密码，然后再次将其作为 HTTP 请求发布到服务器。

第 4 步：服务器 > 验证登录

服务器在数据库中查找用户名，对提供的登录密码进行哈希处理，并将其与数据库中先前哈希处理的密码进行比较。如果不检查，我们可能会通过sending a 401 status code and ending the request 拒绝他们访问。

第 5 步：服务器 > 生成访问令牌

如果一切顺利，我们将创建一个访问令牌，它唯一地标识用户的会话。仍然在服务器中，我们使用访问令牌做两件事：

将其存储在与该用户关联的数据库中
将其附加到要返回给客户端的响应 cookie。请务必设置过期日期/时间以限制用户的会话

此后，cookie 将附加到客户端和服务器之间的每个请求（和响应）。

第 6 步：客户端 > 发出页面请求

回到客户端，我们现在已经登录了。每次客户端请求需要授权的页面（即他们需要登录）时，服务器都会从cookie中获取访问令牌并检查它针对与该用户关联的数据库中的那个。如果它签出，则授予访问权限。

这应该可以帮助您入门。请务必在注销时清除 cookie！

【讨论】：

感谢您的描述。我只是想知道访问令牌如何提供安全性？如果窃取了 cookie，攻击者可以伪装成经过身份验证的登录用户吗？还是受 SSL 保护？
@Richeek SSL 在请求/响应期间保护拦截，但攻击者可能会在端点访问您的 cookie（例如您的浏览器）。理论上，他们可以伪装成登录用户，直到 cookie 过期。我说“理论上”是因为上面的实现没有处理这个问题。在上述实现中，攻击者将拥有访问权限，直到您数据库中的访问令牌被更新（即下一次登录）。
您可能会在自己到期时使访问令牌无效，可能在您的数据库中使用“到期日期”。或者，您可以考虑使用JSON Web Tokens (JWT)，它类似于访问令牌，但可以处理令牌到期等问题。 More on JWT here. 如果攻击者拥有您的访问令牌/JWT，他们仍然可以在短时间内访问您的帐户，因此您还应该保护您的端点。
@ManuChadha 如果请求带有有效的 cookie 但来自错误的 ip、浏览器等，然后您拒绝请求并将用户重定向到登录页面以再次进行身份验证。
最佳做法是在客户端散列密码以进一步降低任何窥探风险。

【解决方案3】：

基于 Cookie 的身份验证

基于 Cookie 的身份验证通常在这 4 个步骤中工作-

用户在登录表单中提供用户名和密码，客户端/浏览器发送登录请求。
发出请求后，服务器通过查询数据库在后端验证用户。如果请求有效，它将使用从数据库中获取的用户信息创建一个会话并存储它们。对于每个会话，都会创建一个称为会话 ID 的唯一 ID。默认情况下，会话 ID 会通过浏览器提供给客户端。
浏览器将在每个后续请求中提交此会话 ID。会话 ID 会根据数据库进行验证。根据这个会话 ID，服务器将识别会话属于哪个客户端，然后授予请求访问权限。
一旦用户退出应用，会话在客户端和服务器端都被销毁。

【讨论】：