前端登陆实现

四种方式

1. Cookie+Session

2. Token

3. SSO 单点登陆

4. OAuth 第三方认证登陆

Cookie+Session

Cookie 出现的原因： HTTP 协议是无状态的，每次请求都会建立一个新的链接，请求结束就会断开链接，优点就是可以节省链接资源，缺点就是无法保存用户状态。Cookie 的出现就是为了解决这个问题。

Cookie 是存储在浏览器中的，可以通过 Js 和 set-cookie 这个响应字段来进行设置。

cookie 的限制：

1. cookie 不能跨域

2. cookie 会在每次 http 的请求时携带

3. 每个 cookie 的大小不能超过 4kb，超过会被截断

4. 每个域名下的 cookie 是有个数限制的，不能超过 20 个

5. cookie 是明文传递的，容易被攻击者窃取，典型的就是 csrf 攻击

有了 cookie 之后，服务端就可以从客户端获取到信息，如果需要对信息进行验证，那么还需要 session

服务端在收到客户端的请求之后，会在服务器中开辟一片内存空间来存放 session

Cookie+Session 认证登陆的基本流程

1. 用户访问 a.com,并且输入用户名和密码

2. 服务器对用户名和密码进行验证，无误后，会创建一个 sessionId 并保存

3. 服务器通过 set-cookie 这个头部将 sessionId 写入到浏览器的 cookie 中

第一次登陆之后，下次再访问的时候就会携带这个 cookie，服务端就可以根据 sessionId 进行验证用户是否登陆（判断这个 sessionId 和服务端保存的 sessionId 是否一致，是否有这个 sessionId 的记录或者记录是否有效）

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。

缺点

1. 如果访问的用户过多，就会导致存储 Session 会占用服务器较大的内存，会对服务器的性能有影响

2. 对于分布式系统，为了保证每台服务器都可以保存用户的登陆状态，可能需要将 session 信息在每台服务器上都保存一份，浪费资源

3. Cookie+Session 的方式会将 sessionId 保存在 cookie 中，所以会造成 csrf 攻击

Token 登陆

Token 是服务器生成的一个字符串，作为客户端请求的一个令牌。第一次登陆之后，服务器会生成一个 Token 返回给客户端，客户端后续访问的时候，只需带上这个 Token 进行身份认证

认证的基本流程

1. 用户首次登陆的时候输入账号密码

2. 服务端确定账号密码无误之后生成一个 Token 返回给客户端（这个 Token 由客户端自由保存）建议不要保存在 cookie 中

再次登陆时

1. 客户端再次访问时会携带这个 Token

2. 服务器验证 Token 正确性，有效则身份认证成功

Token 机制的特点

• 服务端不需要存放 Token 可以降低服务器的压力，而且对于分布式的系统也很友好，没有增加维护成本

• Token 可以存放在客户端的任何位置

缺点

• Token 下发之后，只要在生效时间之内，就一直有效，如果服务器端想收回此 Token 的权限，并不容易。

Token 的生成机制

JWT（Json Web Token）

服务端不需要存储 Token 那么服务端是怎么验证客户端传递过来的 Token 是否有效的呢？

答案：

Token 并不是杂乱无章的字符串，而是通过多种算法拼接而成的字符串

header 部分指定了这个 Token 所使用的签名算法

header = '{"alg":"HS256","typ":"JWT"}'   // `HS256` 表示使用了 HMAC-SHA256 来生成签名。

payload 部分表明了这个 JWT 的意图

payload = '{"loggedInAs":"admin","iat":1422779638}'     //iat 表示令牌生成的时间

signature 部分为 JWT 的签名，主要是为了让 JWT 不被随意的篡改

签名的部分有两个步骤

一：

1. 输入 base64 编码的 header 部分

2. .

3. 输入 base64 编码的 payload 部分

4. 输出 unsignedToken

二:

1. 输入服务器的私钥

2. 输入 unsignedToken

3. 输出 signature

const base64Header = encodeBase64(header)
const base64Payload = encodeBase64(payload)
const unsignedToken = `${base64Header}.${base64Payload}`
const key = '服务器私钥'

signature = HMAC(key, unsignedToken)

最后的 Token 计算如下：

const base64Header = encodeBase64(header)
const base64Payload = encodeBase64(payload)
const base64Signature = encodeBase64(signature)

token = `${base64Header}.${base64Payload}.${base64Signature}`

服务端对 Token 的验证

const [base64Header, base64Payload, base64Signature] = token.split('.')

const signature1 = decodeBase64(base64Signature)
const unsignedToken = `${base64Header}.${base64Payload}`
const signature2 = HMAC('服务器私钥', unsignedToken)

if(signature1 === signature2) {
  return '签名验证成功，token 没有被篡改'
}

const payload =  decodeBase64(base64Payload)
if(new Date() - payload.iat < 'token 有效期'){
  return 'token 有效'
}

SSO 单点登陆

单点登陆指的是公司会搭建一个公共的认证中心，公司里的所有产品的认证都可以在这个认证中心中完成，一个产品在认证中心认证之后，再去访问其他产品时就不需要再次认证

基本认证过程

1. 用户访问 a.com

2. 由于没有进行认证登陆，用户就会被重定向到认证中心页面，并且带上之前访问的页面的 url 以便与认证成功之后返回刚才的页面

3. 用户在认证中心输入账号密码登陆

4. 认证中心验证用户名密码有效就会返回到 a.com?ticket=123 带上授权码 ticket，并将认证中心 sso.com 的登录态写入 Cookie

5. 在 a.com 的服务器中拿着授权码 ticket 去向认证中心确认授权码真实有效

6. 验证成功后，服务器将登录信息写入 Cookie（此时客户端有 2 个 Cookie 分别存有 a.com 和 sso.com 的登录态）。

认证成功之后再次访问相同域名

这个时候，由于 a.com 存在已登录的 Cookie 信息，所以服务器端直接认证成功。

访问 b.com

这个时候由于认证中心存在之前登陆过的 cookie，所以不需要再输入账号密码，直接从第四步开始执行

1. 认证中心返回到 b.com?ticket=123，并将认证中心的登陆状态写入到 cookie

2. 在 b.com 的服务器中拿着授权码去认证中心认证其有效性

3. 认证成功之后，将 b.com 的登陆信息写入 cookie（此时客户端有两个 cookie 登陆中心 和 b.com）

SSO 单点登陆的退出

目前我们已经完成了单点登录，在同一套认证中心的管理下，多个产品可以共享登录态。现在我们需要考虑退出了，即：在一个产品中退出了登录，怎么让其他的产品也都退出登录？

原理也不难，其实就是在携带 ticket 去请求认证中心的时候，再去请求一下认证中心的退出登陆的 api 即可

当某个产品 c.com 退出登陆时

1. 清除 c.com 中的登陆态 cookie

2. 请求认证中心的退出登陆的 api

3. 认证中心遍历下发过 ticket 的所有产品，并调用对应的退出 api，完成退出。

SSO 的优点

sso 就是一个集中地验证系统。你项目内请求时，向 sso 发一个请求，他给你个 token 你扔到游览器缓存里，请求的时候放在请求头里带着。和其他验证接口一样。 他好就好在，一个账号在不同系统里都可以登录，因为不同项目可以共用这个 token。并且通过 sso 集中管理一些用户信息，你可以方便的拿用户信息。

OAuth 第三方登陆

以微信为例子

1. 首先 a.com 的运营者需要在微信开放平台注册账号，并申请使用微信登陆功能

2. 申请成功之后得到申请的 appid,appsecret

3. 用户在 a.com 上使用微信登陆就会跳转到微信的 OAuth 授权登陆，并携带当前所在的 url

4. 用户输入微信的账号密码，登陆成功之后，选择授权的信息（比如头像，昵称等）

5. 授权之后微信会返回 a.com?code=123，并携带一个临时票据

6. 在 a.com 中获取到临时票据 code 之后，a.com 会将 appid,appsecret,code 发送给微信申请一个 token，微信认证成功之后就会下发一个 token

7. 有了这个 token 之后，a.com 就可以通过这个 token 拿到用户的头像和昵称等信息了。

8. a.com 提示用户登陆成功，并将登陆状态写入到 cookie，作为后续访问的凭证