0%

WEB认证授权1—Cookie/Seesion Auth

发表于 2019-07-10 更新于 2023-03-28 分类于 WEB安全， Browser端安全

HTTP是一种没有状态的协议，它并不知道是谁访问了应用。所以服务器必须记录用户的状态，进行认证、授权，进而控制用户操作。
随着技术的发展出现了很多认证授权机制。目前，比较成熟完善的是 Cookie/Session 机制。近几年，由于JWT机制更好得释放了服务端的资源，也变得火热起来。不过，还不够成熟容易出现很多问题。
所以，在更高效、更安全的方案出现前，Cookie/Session 机制可能仍然是将来Web认证授权的中流砥柱。

0x01 HTTP Basic Auth

HTTP Basic Auth是最原始的认证方式，现在已经被淘汰

1 原理

每次请求API时都提供用户的username和password

2 优点

配合RESTful API 使用的最简单的认证方式，只需提供用户名密码即可

3 缺点

有暴露用户名和密码给第三方客户端的风险

Cookie/Session Auth是通用解决HTTP无状态进行认证授权的机制。通常把Session机制理解为会话（即：有状态）。
很多人区分不开Cookie与Session。下面加粗部分及结合原理部分可以仔细揣摩进行区分。谁在客户端？谁在服务端？谁携带SeesionID？两者之间什么关系？

Cookie 属于一种内建于浏览器中实现状态的方式。
Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，以达到认证的目的。也是实现Session跟踪的一种方式。
Cookie另一用途：登录过一个网站，下次登录不想再输入账号怎么办？这个信息可以写到Cookie里面。访问网站的时候网站页面的脚本可以读取这个信息，自动把用户名填上。这也是Cookie的由来（Cookie英文意思是饼干，给用户的一点甜头。）

2 Session

Session是在服务端保存的一个数据结构。用来跟综标识用户的状态。

每次HTTP请求时，客户端都会发送相应携带SeesionID的Cookie信息到服务端。进而，实现了有状态
用户在浏览器登陆之后（正确的密码，第一层认证通过），服务端为用户生成唯一的 Session ID，存储在服务端的存储服务（例如 MySql, Redis）中
该 Session ID也同时返回给浏览器，以 SESSION_ID 为 KEY 存储在浏览器的 Cookie 中
如果用户再次访问该网站，Cookie 里的 SESSION_ID 会随着请求一同发往服务端
服务端通过判断 SESSION_ID 是否已经在 Redis 中判断用户是否处于登陆状态

几乎动态网站都有用应用
比如：淘宝买东西，下单后由于HTTP无状态所以并不知道哪个用户所操作的。所以服务器要为特定的用户创建特定的Session用于标识这个用户，并且跟踪用户

数据需要客户端和服务器同时存储（故，消耗了服务器资源）
用户进行操作时，需要带上cookie，在服务器进行验证（可能存在Cookie劫持、盗取）
有状态

1 扩展性不好

如果服务器集群（或者跨域的服务导向架构）要求Session数据共享，每台服务器都能够读取Session
例如：A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，怎么实现？
一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。
另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。JWT 就是这种方案的一个代表。

2 希望无状态的API时-不推荐使用

在构建 API 时，开发者会发现认证方式和网页应用有一些不同，除了像 ajax 这种典型的 web 技术外，如果希望 API 是无状态的，不推荐使用 Cookie。