身份认证技术，也就是所谓的登录功能，是现代WEB系统最常见的功能之一。本系列文章就试图为大家详细的介绍身份认证技术。

Basic认证模式是较早被广泛应用的一种HTTP标准提供的认证模式。最常见的形式之一就是在url中直接写上用户名密码向服务器提供身份：

http://user:[email protected]/index.html

在Basic模式之中，每次向服务器请求受保护资源的时候都要在url中带上明文或仅被Base64编码过的用户名密码。而且在这种模式下，如果我们要实现“记住登录状态”功能，就需要将用户名密码这样的敏感信息直接换存在浏览器中。这样就形成了它最主要的两个缺点：

1、每个请求中都要带有用户名和密码凭据

2、安全性堪忧

为了解决每次请求敏感资源都要带有用户名密码凭证的问题，web开发者们形成了一套基本的实践模式，就是将用户认证后的身份存储于服务端管理的会话（session）之中，以此来减少使用过程中对凭据的传输。

​用户想要请求受保护资源，先要登录，想服务端发送用户名密码。服务端验证用户名密码成功之后将用户的身份验证标识存储在session 中，然后将sessionId存储在cookie 中。之后当客户再去请求受保护资源的时候，只要携带好cookie中的sessionId就可以验证其身份返回敏感数据了。

这种基于session的认证模式犹豫其简单、方便、好用，所以被广泛使用。但是随着web应用的发展，其也出现了诸多不足：

1、当服务器应用重启时，用户会被强制登出

2、当站点用负载均衡部署多份时，每个站点实例的session无法共享

当然，我们可以使用单独的session存储服务来解决这些问题，但这样会增加系统不小的复杂性与维护成本。

既然使用session会产生诸多的问题，那我们是不是可以有一种类似的方案来解决这种问题呢？答案肯定是有的，那就是将认证信息直接存储在客户端的cookie中。

但是存在客户端就会面临着一系列的安全问题，例如，我直接在cookie中以用户id存储标识，那是不是用户自己篡改cookie改称别的用户id就可以切换自己的身份了呢？因此这就要涉及到cookie信息加密和解密。

除了加密与解密以外还有现在常用的一种解决方案：就是存储票据（ticket）。在用户登录成功之后，站点生成一个ticket，一方面将用户身份信息存储在服务端缓存中，以ticket为key；另一方面，将ticket存储到用户的cookie中。这样，用户再要访问敏感信息时，只需要每次都带上自己cookie中的ticket就可以了。这种方法其实和使用session很像，但是因为现在基本上缓存服务已经属于必备的基础组建了，所以并不会增加过多额外的成本，而且缓存服务相比session也比较好做长时间的数据存储。