身份认证系统（一）单WEB应用的身份认证

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

Basic认证模式

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

http://user:passwd@www.server.com/index.html

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

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

二、安全性堪忧

基于session的认证模式

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

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

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

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

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

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

基于cookie的认证模式

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

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

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

 

 

 

转：https://www.cnblogs.com/meibaorui/p/9171878.html