身份认证系统(一)单WEB应用的身份认证
身份认证技术,也就是所谓的登录功能,是现代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也比较好做长时间的数据存储。
转:https://www.cnblogs.com/meibaorui/p/9171878.html