几种常用的认证机制对比

HTTP Basic Auth

每次请求API时都提供用户的 账号与密码 ,它是配合RESTful API 使用最简单的认证方式,只需提供用户名密码即可,但是由于这样会把用户名和密码直接暴露给第三方客户端的风险,所以尽量避免采用 HTTP Basic Auth

OAuth

OAuth 是一个开放的授权标准,允许用户让第三方应用访问该用户在某一web服务上存储的私密资源,而无需将用户名和密码提供给第三方应用

OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容

OAuth 流程图

Cookie Auth

Cookie 认证机制就是为一次请求认证在服务端创建一个 session 对象,同时在客户端的浏览器端创建了一个Cookie对象,通过客户端带上来Cookie对象来与服务器端的session对象来匹配实现状态管理。

Tocken Auth

使用Token Auth的流程:客户端使用用户名和密码请求登录,服务端收到请求,验证用户名和密码。验证成功后,服务端会生成一个token,然后把这个token发送给客户端。客户端收到token后把它存储起来,可以放在cookie或者Local Storage(本地存储)里。客户端每次向服务端发送请求的时候都需要带上服务端发给的token。服务端收到请求,然后去验证客户端请求里面带着token,如果验证成功,就向客户端返回请求的数据。

Tocken Auth 流程图

基于JWT的Tocken认证机制实现

JWT 是 (JSON Web Tocken) 的缩写,它是一个非常轻巧的规范,这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息

JWT的组成

一个JWT实际上就是一个字符串,它由三部分组成:头部、载荷与签名

载荷(payload):

载荷

iss:该JWT的签发者,是否使用是可选的

sub:该JWT所面向的用户,是否使用是可选的

aud:接收该JWT的一方,是否使用是可选的

exp(expires):什么时候过期,这里是一个Unix事件戳,是否使用是可选的

iat(issued at):在什么时候签发的(UNIX事件),是否使用是可选的

nbf(Not Before):如果当前时间在nbf里的时间之前,则Tocken不被接受;一般都会留一些余地,比如几分钟;是否使用是可选的

将上面的JSON对象进行 base64编码 可以得到下面的字符串。这个字符串 我们将它称作JWT的Payload(载荷)

eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

头部(Header)

JWT 头部用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等,他也可以表示成一个json对象

头部

上图中在JWT头部指明了签名算法是HS256算法

头部也要进行BASE64编码,编码后的字符串如下:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

签名(Signature)
将 载荷和头部 编码后的字符串都用句号 . 连接起来(头部在前),就形成了

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

最后我们将上面拼完的字符串用HS256算法进行加密,在加密的时候,我们还需要提供一个密钥(secret),如果我们用 mystart 作为密钥的话,那么就可以得到我们加密后的内容:

rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

最后将这一部分签名也拼接在被签名的字符串后面,我们就得到了完整的JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

在我们的请求URL中会带上这串JWT字符串:

https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

Tocken Auth的优点

Tocken机制相对于Cookie机制的好处:

1.支持跨域访问:Cookie是不允许跨域访问的,这一点对Tocken机制是不存在的,前提是传输的用户认证信息通过HTTP头传输

2.无状态(也称:服务端可扩展行):Tocken机制在服务端不需要存储session信息,因为Tocken自身包含了所有登录用户的信息,只需要在客户端的cookie或本地介质存储状态信息

3.更适用CDN:可以通过内容分发网络请求你服务端的所有资料(如:javascript,HTML,图片等),而你的服务端只要提供API即可

4.去藕:不需要绑定到一个特定的身份验证方案。Tocken可以在任何地方生成,只要在你的API被调用的时候,你可以进行Tocken生成调用即可

5.更适用于移动应用: 当你的客户端是一个原生平台(iOS, Android,Windows 8等)时,Cookie是不被支持的(你需要通过Cookie容器进行处理),这时采用Token认证机制就会简单得多。

6.CSRF:因为不再依赖于Cookie,所以你就不需要考虑对CSRF(跨站请求伪造)的防范。

7.性能: 一次网络往返时间(通过数据库查询session信息)总比做一次HMACSHA256计算 的Token验证和解析要费时得多.

8.不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候,不再需要为登录页面做特殊处理.

9.基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库(.NET, Ruby, Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft).

你可能感兴趣的:(几种常用的认证机制对比)