身份认证系统(一)单WEB应用的身份认证

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

Basic认证模式

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

在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://kuaibao.qq.com/s/20180515G1EEXG00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券