一，登录认证流程

用户初次登录的简单流程：

在用户登录完毕之后 **，直到用户退出登录之前的请求都被归属为一次会话 **，这就需要使用到会话技术了。

二，会话技术

• 会话：用户打开浏览器，访问web服务器的资源，会话建立，直到有一方断开连接，会话结束。在一次会话中可以包含多次请求和响应。
• 会话跟踪：一种维护浏览器状态的方法，服务器需要识别多次请求是否来自于同一浏览器，以便在同一次会话的多次请求间共享数据
• 会话跟踪方案：
  • 客户端会话跟踪技术：Cookie
  • 服务端会话跟踪技术：Session
  • 令牌技术token

2.1 Cookie

HTTP 是一种无状态的协议，客户端每次发送请求时，首先要和服务端创建一个连接，在请求完成之后会断开这个连接。这种方式能够节省传输时占用的连接资源，但同时也存在一个问题：每次请求都是独立的，服务器没法判断本次请求和上一次请求是否来自同一个用户，进而也没法判断用户的登录状态，为了解决 HTTP 无状态的问题，Lou 等在 1994 年的时候，推出了Cookie。

Cookie 原理：在浏览器中，Cookie 是服务器让浏览器帮忙携带信息的手段，就像饼干里的纸条，浏览器会储存它，并且在后续的 HTTP 请求中再次发送给服务器。

因为 Cookie 是 Http 协议支持的技术，

• 服务端通过响应头里面设置Set-Cookie值来将 cookie 传递给浏览器。

• 浏览器通过请求头里面的Cookie 将cookie 值传递给服务端。

跨域区分三个维度：协议、IP 地址、域名、端口。只要三个中有任何一个不同，这次请求就是跨域请求。如下图

2.2 Session

有了 Cookie 之后，服务端就可以获取到客户端传递过来的信息，若是需要对信息进行验证，还需要经过Session。

Session 原理： 存在服务器的一种用来存放用户数据的类哈希表结构

• 当浏览器第一次发送请求的时候服务器会生成一个hashtable和一个sessionid，sessionid 来唯一标识这个 hashtable，响应的时候会通过一个响应头 set-cookie 返回给浏览器，浏览器再将这个 sessionid 存储在一个名为 JESSIONID 的 cookie 中。

• 浏览器在发送第二次请求时，就会带上这个 cookie，这个 cookie 会存储 sessionid 一并发 ] 送给了一个服务，服务器再从请求中提取出对应的一个 sessionid 并和当前保存的所有的一个 sessionid 去进行一个对比然后找到这个 sessionid 对应的用户信息。

2.3 令牌token

令牌原理： 令牌就是用户身份的标识，本质是一串字符串。

• 当用户登录成功后，服务端会生成一个令牌，将令牌响应给浏览器。
• 浏览器接收到令牌后将令牌存储起来，在后续每一次请求中，都将这个令牌携带到服务端。
• 服务端接收到令牌后会校验这个令牌的有效性，如果令牌有效代表用户成功登录了，无效代表用户未登录。
• 在同一次会话的多次请求之间将共享的数据存储在令牌之中。

三，常见登录验证方式

3.1 Cookie+Session登录

Cookie+Session 的登录方式是最经典的一种登录方式，如今仍有大量企业在用。

用户首次登录时：

1. 先访问a.com/login，输入账号密码登录。
2. 服务器验证密码无误后，会建立SessionId，并将它保存起来。
3. 服务端响应这个HTTP请求，并经过Set-Cookie头信息，将SessionId写入Cookie中。
4. 浏览器会根据Set-Cookie中的信息，自动将SessionId存储在cookie中。

第一次登录完成之后，后续的访问就能够直接使用 Cookie 进行身份验证了：

1. 用户访问a.com/page页面时，会自动带上第一次登录时写入的Cookie。
2. 服务端对比Cookie中的SessionId和保存在服务端的SessionId是否一致。
3. 若是一致，则身份验证成功

Cookie+Session 存在的问题

虽然这种使用 Cookie+Session 的方式完成了登录验证，但仍然存在一些问题：

• 因为服务端需要对接大量的客户端，就需要存放大量的SessionId，会导致服务端压力过大。
• 若服务端是一个集群，需要将SessionId同步到每一台机器上，无形中增长了服务端维护成本。
• 因为SessionId存放在Cookie中，因此没法避免CSRF攻击。

CSRF 攻击是一种利用用户在目标网站上已认证的会话执行非预期操作的攻击方式。攻击者通过欺骗用户使其在受信任的网站上执行恶意操作，如转账、修改账户信息等。常见的 CSRF 攻击方式，如下：

1. 直接链接方式，攻击者通过诱使用户点击恶意链接，向目标网站发送伪造请求。当用户点击链接时，浏览器会自动发送包含用户认证信息的请求，从而执行攻击者指定的操作。
2. 图片/资源引用方式，攻击者将恶意请求嵌入到图片、脚本或其他资源引用中，并将其插入到受信任网站的页面。当用户访问页面时，浏览器会自动加载并发送恶意请求。
3. 表单提交方式，攻击者创建一个包含恶意请求的表单，并将其隐藏在一个看似正常的页面中。当用户在该页面上执行某些操作（如点击按钮）时，浏览器会自动提交表单，从而执行攻击者指定的操作。

3.2 Token登录认证

为了解决 Session+Cookie 机制暴露出的诸多问题，我们可使用 Token 的登录方式。

Token 是服务端生成的一串字符串，以作为客户端请求的一个令牌。当第一次登录后，服务端会生成一个 Token 并返回给客户端，客户端后续访问时，只要携带这个 Token 就能完成认证。

Token 机制实现流程

• 用户首次登录时：
  1. 用户访问a.com/login，输入账号密码，并点击登录。
  2. 服务端验证账号密码无误，建立Token。
  3. 服务端将Token返回给客户端，由客户端自由保存。
• 后续访问页面时
  1. 用户访问a.com/page时，带上第一次登录时获取的Token。
  2. 服务端验证Token，有效则身份验证成功。

Token 机制特色

• 服务端不需要存放Token，因此不会对服务端形成压力，即便是服务器集群，也不需要增长维护成本。
• Token能够存放在前端任何地方，能够不保存在Cookie中，提高了页面安全性。
• Token下发之后，只要在生效时间内，就一直生效**，若服务端想要收回此Token权限，并不容易。

Token 的生成方式

• 最常见的Token生成方式是使用JWT，即Json Web Token，它采用一种简洁的，自包含的方法，用于通讯双方之间以JSON对象的形式安全的传递信息。
• JWT算法主要分为3个部分：header（头信息）、playload（消息体）、signature（签名）
• header部分指定了该JWT使用的签名算法。
• playload代表了JWT的意图。
• signatrue部分为JWT的签名，主要为了让JWT不能被随意篡改。

3.3 SSO单点登录

单点登录指在公司内部搭建的一个公共认证中心，公司下的全部产品登录均可以在认证中心完成，一个产品在认证中心登录之后，再去访问另外一个产品，能够不用再次登录，便获取登录状态。

SSO 机制实现流程

• 用户首次访问时，需要在认证中心登录：
  1. 用户访问网站a.com/pageA页面。
  2. 因为没有登录，会重定向到认证中心，并带上回调地址www.sso.com?return_uri=a.com/pageA，以便登录后直接进入对应页面。
  3. 用户在认证中心输入账号密码，提交登录。
  4. 认证中心验证账号密码有效，后重定向到a.com?ticket=123，带上授权码ticket，并将认证中心sso.com的登录态写入Cookie。
  5. 在a.com服务器上，拿着ticket向认证中心确认，授权码ticket真实有效。
  6. 验证成功后，服务器将登录信息写入Cookie（此时客户端有两个Cookie，分别存有a.com和sso.com的登录态信息）

认证中心完成登录后，继续访问 a.com 的其余页面，由于此时a.com已经存了 Cookie 信息，服务端直接认证成功。 如果要访问认证中心已存的b.com的页面，由于认证中心存在以前登录过的 Cookie，也就不用再输入账号密码，直接返回第四步，下发 ticket 给b.com即可。

• SSO 单点登录退出

  完成单点登录后，在同一套认证中心管理下，多个产品能够共享登录状态，但是还有一个问题：在一个产品中退出了登录状态，怎么让其余产品也退出登录？

  原理并不难，回过头来看第 5 步，每个产品在向认证中心验证ticket时，能够顺带将本身的退出登录 api 发送到认证中心。当某个产品c.com退出登录时

  1. 清空c.com中的登录态Cookie。
  2. 请求认证中心sso.com中的退出api
  3. 认证中心遍历下发过ticket的全部产品，并调用对应的退出api，完成退出。

常用的 SSO 单点登录框架为：CAS

• CAS是一个开源项目，CAS是应用于企业级别的单点登录的服务，CAS分为CAS Server，CAS Client
• CAS Server是需要一个单独部署的Web工程
• CAS Client是一个项目中的具体业务服务，并且在需要认证或授权时，找到CAS Server即可
• 整体CAS的认证和授权流程就是中心化的方式

3.4 OAuth第三方登录

除了上述的认证方式，也可以引入第三方厂家提供的登录服务。如微博、微信、QQ 等提供的登录认证接口，均能实现登录过程。

四，用户认证，授权经典表设计

用户认证、授权时推荐的表结构设计，经典五张表！