【发布时间】：2014-01-21 06:51:48
【问题描述】：
当浏览器客户端成功向服务器提交用户名/电子邮件和密码并且客户端从服务器检索数据的下一个请求时，如何识别客户端已成功通过身份验证？
我找到了这个信息：
“在用户输入凭据后，浏览器会在会话期间自动将后续请求发送到同一域。”
浏览器从哪里获取每个后续请求的凭据？
我是否必须主动将凭据保存在某处？魔法是如何发生的？
【问题讨论】：
标签： asp.net-web-api basic-authentication
【发布时间】：2014-01-21 06:51:48
【问题描述】：
一旦用户的凭据被服务器认证，服务器会返回一个授权令牌（通常称为身份验证令牌，它是一个由字符和数字组成的长字符串），用于标识用户已通过身份验证并且是有效的。每次，用户在他的请求中发送，请求数据也将包含此身份验证令牌（作为 cookie 或添加到请求本身），让服务器知道客户端是有效的。因此，请求每次都经过身份验证，而不是使用实际的用户名/密码凭据。
根据要求，可以将身份验证令牌设置为在一段时间后过期（如果没有活动，例如在银行应用程序中）。
【讨论】：
-
我认为令牌身份验证是基本身份验证的额外内容。所以令牌使用总是与基本身份验证一起使用？
-
第一步是基本身份验证，服务器检查数据库以查看用户名/密码是否匹配。如果是，则服务器会生成一个唯一的身份验证令牌（并且对于该特定凭证和该特定会话来说它是唯一的 - 会话的长度取决于要求）。从这里开始，每个请求只对令牌进行身份验证。此时在每个步骤中传递用户名/密码只是额外的开销，并使系统对恶意意图更加开放。我希望这能回答你的想法。
-
此外，密码通常在请求中立即使用只有服务器知道并可以解密的算法进行加密（一些示例是 base64、SHA、MD5，尽管它们中的大多数都有自己的实现，因为它会很容易解密这些）。加密/解密过程增加了一些开销。这就是为什么您第一次登录时可能会注意到加载时间稍长，但一旦您进入，页面之间的导航相对更快。每个步骤的加密/解密都会使用户体验变慢。
-
当我 google 进行基本身份验证时，http 规范的目的只是期望用户名：授权标头中未加密但使用 base64 编码的密码，并且方案必须是“基本”就是这样。现在我问自己（委员会？）后续请求的象征性想法从何而来？
-
有一种称为拦截器的设计模式（例如 Spring 中的拦截器），通常用于提供对安全站点的访问。例如，您输入银行帐户页面的网址 - 会发生什么？您将被重定向到登录页面。这是因为，拦截器首先拦截此请求，并发现此请求没有关联的身份验证令牌，因此必须未经身份验证，从而将您重定向到登录页面。相同的拦截器（通常）设置为拦截对所有安全 url 的请求。