身份认证技术，也就是所谓的登录功能，是现代WEB系统最常见的功能之一。本系列文章就试图为大家详细的介绍身份认证技术。
Basic认证模式Basic认证模式是较早被广泛应用的一种HTTP标准提供的认证模式。最常见的形式之一就是在url中直接写上用户名密码向服务器提供身份：
http://user:passwd@www.server.com/index.html
在Basic模式之中，每次向服务器请求受保护资源的时候都要在url中带上明文或仅被Base64编码过的用户名密码。而且在这种模式下，如果我们要实现“记住登录状态”功能，就需要将用户名密码这样的敏感信息直接换存在浏览器中。这样就形成了它最主要的两个缺点：
1、每个请求中都要带有用户名和密码凭据
2、安全性堪忧
基于session的认证模式为了解决每次请求敏感资源都要带有用户名密码凭证的问题，web开发者们形成了一套基本的实践模式，就是将用户认证后的身份存储于服务端管理的会话（session）之中，以此来减少使用过程中对凭据的传输。
用户想要请求受保护资源，先要登录，想服务端发送用户名密码。服务端验证用户名密码成功之后将用户的身份验证标识存储在session 中，然后将sessionId存储在cookie 中。之后当客户再去请求受保护资源的时候，只要携带好cookie中的sessionId就可以验证其身份返回敏感数据了。
这种基于session的认证模式犹豫其简单、方便、好用，所以被广泛使用。但是随着web应用的发展，其也出现了诸多不足：
1、当服务器应用重启时，用户会被强制登出
2、当站点用负载均衡部署多份时，每个站点实例的session无法共享
当然，我们可以使用单独的session存储服务来解决这些问题，但这样会增加系统不小的复杂性与维护成本。
基于cookie的认证模式既然使用session会产生诸多的问题，那我们是不是可以有一种类似的方案来解决这种问题呢？答案肯定是有的，那就是将认证信息直接存储在客户端的cookie中。
但是存在客户端就会面临着一系列的安全问题，例如，我直接在cookie中以用户id存储标识，那是不是用户自己篡改cookie改称别的用户id就可以切换自己的身份了呢？因此这就要涉及到cookie信息加密和解密。
除了加密与解密以外还有现在常用的一种解决方案：就是存储票据（ticket）。在用户登录成功之后，站点生成一个ticket，一方面将用户身份信息存储在服务端缓存中，以ticket为key；另一方面，将ticket存储到用户的cookie中。这样，用户再要访问敏感信息时，只需要每次都带上自己cookie中的ticket就可以了。这种方法其实和使用session很像，但是因为现在基本上缓存服务已经属于必备的基础组建了，所以并不会增加过多额外的成本，而且缓存服务相比session也比较好做长时间的数据存储。
随时随地看视频
