鉴权的几种方式介绍对比

发表于 更新于 分类于

转载于知乎

背景

说起鉴权大家应该都很熟悉，不过作为前端开发来讲，鉴权的流程大头都在后端小哥那边，本文的目的就是为了让大家了解一下常见的鉴权的方式和原理。

认知：HTTP 是一个无状态协议，所以客户端每次发出请求时，下一次请求无法得知上一次请求所包含的状态数据。

一、HTTP Auth Authentication

简介

HTTP 提供一个用于权限控制和认证的通用框架。最常用的HTTP认证方案是HTTP Basic Authentication

img

鉴权流程

img

加解密过程

1
2
3
4
5
6
7
8
9
10
// Authorization 加密过程
let email = "postmail@test.com"
let password = "12345678"
let auth = `${email}:${password}`
const buf = Buffer.from(auth, 'ascii');
console.info(buf.toString('base64')); // cG9zdG1haWxAdGVzdC5jb206MTIzNDU2Nzg=

// Authorization 解密过程
const buf = Buffer.from(authorization.split(' ')[1] || ''),  'base64');
const user = buf.toString('ascii').split(':');

其他 HTTP 认证

通用 HTTP 身份验证框架有多个验证方案使用。不同的验证方案会在安全强度上有所不同。

IANA 维护了一系列的验证方案，除此之外还有其他类型的验证方案由虚拟主机服务提供，例如 Amazon AWS ，常见的验证方案包括：

  • Basic (查看 RFC 7617, Base64 编码凭证. 详情请参阅下文.),
  • Bearer (查看 RFC 6750, bearer 令牌通过OAuth 2.0保护资源),
  • Digest (查看 RFC 7616, 只有 md5 散列 在Firefox中支持, 查看 bug 472823 用于SHA加密支持),
  • HOBA (查看 RFC 7486 (草案), HTTP Origin-Bound 认证, 基于数字签名),
  • Mutual (查看 draft-ietf-httpauth-mutual),
  • AWS4-HMAC-SHA256 (查看 AWS docs)

二、Cookie + Session

注册流程

img

思考：为什么要在密码里加点“盐”？

鉴权流程

img

Session 存储

最常用的 Session 存储方式是 KV 存储，如Redis，在分布式、API 支持、性能方面都是比较好的，除此之外还有 mysql、file 存储。

如果服务是分布式的，使用 file 存储，多个服务间存在同步 session 的问题；高并发情况下错误读写锁的控制。

Session Refresh

我们上面提到的流程中，缺少 Session 的刷新的环节，我们不能在用户登录之后经过一个 expires 时间就把用户踢出去，如果在 Session 有效期间用户一直在操作，这时候 expires 时间就应该刷新。

以 Koa 为例，刷新 Session 的机制也比较简单： 开发一个 middleware（默认情况下所有请求都会经过该 middleware），如果校验 Session 有效，就更新 Session 的 expires: 当前时间+过期时间。

img

优化：

  1. 频繁更新 session 会影响性能，可以在 session 快过期的时候再更新过期时间。
  2. 如果某个用户一直在操作，同一个 sessionID 可能会长期有效，如果相关 cookie 泄露，可能导致比较大的风险，可以在生成 sessionID 的同时生成一个 refreshID，在 sessionID 过期之后使用 refreshID 请求服务端生成新的 sessionID（这个方案需要前端判断 sessionID 失效，并携带 refreshID 发请求)。

单设备登录

有些情况下，只允许一个帐号在一个端下登录，如果换了一个端，需要把之前登录的端踢下线（默认情况下，同一个帐号可以在不同的端下同时登录的）。

这时候可以借助一个服务保存用户唯一标识和 sessionId 值的对应关系，如果同一个用户，但 sessionId 不一样，则不允许登录或者把之前的踢下线(删除旧 session )。

三、JWT

简介

JSON Web Token (JWT)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

JWT 组成

JWT 由三部分组成，分别是 header(头部)，payload(载荷)，signature(签证) 这三部分以小数点连接起来。

例如使用名为 jwt-token 的cookie来存储 JWT 例如：

1
jwt-token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoibHVzaGlqaWUiLCJpYXQiOjE1MzI1OTUyNTUsImV4cCI6MTUzMjU5NTI3MH0.WZ9_poToN9llFFUfkswcpTljRDjF4JfZcmqYS0JcKO8;

使用.分割值可以得到三部分组成元素，按照顺序分别为：

  • header：

      • 值：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
    • Base64 解码: {"alg": "HS256", "type": "JWT"}

  • payload：

      • 值：eyJuYW1lIjoibHVzaGlqaWUiLCJpYXQiOjE1MzI1OTUyNTUsImV4cCI6MTUzMjU5NTI3MH0
    • Base64 解码：
1
2
3
4
5
{       
    "name": "lushijie",        
    "iat": 1532595255, // 发布时间       
    "exp": 1532595270 // 过期时间     
}

  • signature：

      • 值：WZ9_poToN9llFFUfkswcpTljRDjF4JfZcmqYS0JcKO8
    • 解码：
1
2
3
const headerEncode = base64Encode(header);     
const payloadEncode = base64Encode(payload);     
let signature = HMACSHA256(headerEncode + '.' + payloadEncode, '密钥');

特点

  • 防CSRF（主要是伪造请求，带上cookie）
  • 适合移动应用 app

鉴权流程

img

Token 校验

对于验证一个 JWT 是否有效也是比较简单的，服务端根据前面介绍的计算方法计算出 signature，和要校验的JWT中的 signature 部分进行对比就可以了，如果 signature 部分相等则是一个有效的 JWT。

Token Refresh

为了减少 JWT Token 泄露风险，一般有效期会设置的比较短。 这样就会存在 JWT Token 过期的情况，我们不可能让用户频繁去登录获取新的 JWT Token。

解决方案：

可以同时生成 JWT Token 与 Refresh Token，其中 Refresh Roken 的有效时间长于 JWT Token，这样当 JWT Token 过期之后，使用 Refresh Token 获取新的 JWT Token 与 Refresh Token，其中 Refresh Token 只能使用一次。

四、OAuth

阮一峰通俗介绍OAuth

OAuth 2.0 的四种方式 - 阮一峰的网络日志www.ruanyifeng.com图标

下面是转载，防止链接失效

RFC 6749

OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。

OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。……资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。

这段话的意思就是，OAuth 的核心就是向第三方应用颁发令牌。然后，RFC 6749 接着写道：

（由于互联网有多种场景，）本标准定义了获得令牌的四种授权方式（authorization grant ）。

也就是说，OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。

  • 授权码（authorization-code）
  • 隐藏式（implicit）
  • 密码式（password）：
  • 客户端凭证（client credentials）

注意，不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份，然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

第一种授权方式：授权码

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

第一步，A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

1
2
3
4
5
https://b.com/oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read

上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）。

img

第二步，用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样。``

1
https://a.com/callback?code=AUTHORIZATION_CODE

上面 URL 中，code参数就是授权码。

img

第三步，A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

1
2
3
4
5
6
https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL

上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

img

第四步，B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

1
2
3
4
5
6
7
8
9
{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

img

第二种方式：隐藏式

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）”隐藏式”（implicit）。

第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

1
2
3
4
5
https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

上面 URL 中，response_type参数为token，表示要求直接返回令牌。

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。

1
https://a.com/callback#token=ACCESS_TOKEN

上面 URL 中，token参数就是令牌，A 网站因此直接在前端拿到令牌。

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在”中间人攻击”的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

img

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

第三种方式：密码式

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为”密码式”（password）。

第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

1
2
3
4
5
https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

上面 URL 中，grant_type参数是授权方式，这里的password表示”密码式”，username和password是 B 的用户名和密码。

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

第四种方式：凭证式

最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。

第一步，A 应用在命令行向 B 发出请求。

1
2
3
4
https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

上面 URL 中，grant_type参数等于client_credentials表示采用凭证式，client_id和client_secret用来让 B 确认 A 的身份。

第二步，B 网站验证通过以后，直接返回令牌。

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

令牌的使用

A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。

此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

1
2
curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

上面命令中，ACCESS_TOKEN就是拿到的令牌。

更新令牌

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

1
2
3
4
5
https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

上面 URL 中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。

B 网站验证通过以后，就会颁发新的令牌。

写到这里，颁发令牌的四种方式就介绍完了。下一篇文章会编写一个真实的 Demo，演示如何通过 OAuth 2.0 向 GitHub 的 API 申请令牌，然后再用令牌获取数据。

https://link.zhihu.com/?target=https%3A//blog.csdn.net/maxchenBug/article/details/88791514)

五、总结对比

没有最好，只有最合适！！！

HTTP Auth Authentication

  • 梳理总结：

    • 通用 HTTP 身份验证框架有多个验证方案使用。不同的验证方案会在安全强度上有所不同。HTTP Auth Authentication 是最常用的 HTTP认证方案，为了减少泄露风险一般要求 HTTPS 协议。

  • 适用场景

    • 一般多被用在内部安全性要求不高的的系统上，如路由器网页管理接口

  • 问题：

    • 请求上携带验证信息，容易被嗅探到
    • 无法注销

  • 梳理总结：

    • 服务端存储 session ，客户端存储 cookie，其中 cookie 保存的为 sessionID
    • 可以灵活 revoke(撤销) 权限，更新信息后可以方便的同步 session 中相应内容
    • 分布式 session 一般使用 redis(或其他KV) 存储

  • 使用场景：

    • 适合传统系统独立鉴权

JWT

  • 梳理总结：

    • 服务器不再需要存储 session，服务器认证鉴权业务可以方便扩展
    • JWT 并不依赖 cookie（防范CSRF），也可以使用 header 传递
    • 为减少盗用(中间人)，要使用 HTTPS 协议传输

  • 适用场景：

    • 适合做简单的 RESTful API 认证
    • 适合一次性验证，例如注册激活链接

  • 问题：

    • 使用过程中无法废弃某个 token，有效期内 token 一直有效
    • payload 信息更新时，已下发的 token 无法同步

OAuth

  • 梳理总结：

    • OAuth是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。
    • GitHub OAuth 文档 Identifying and authorizing users for GitHub Apps

  • 适用场景：OAuth 分为下面四种模式

    • 简化模式，不安全，适用于纯静态页面应用
    • 授权码模式，功能最完整、流程最严密的授权模式，通常使用在公网的开放平台中
    • 密码模式，一般在内部系统中使用，调用者是以用户为单位。
    • 客户端模式，一般在内部系统之间的 API 调用。两个平台之间调用，以平台为单位。

转载于知乎

延伸阅读

单点登录注销_Faker_Wang的博客-CSDN博客blog.csdn.net

[《手机扫码登录内网怎么实现的？》blog.csdn.net](