API鉴权及JWT详细分析

Web API常见的鉴权方法,即WebAPI中保障请求合法性的常见方法：

(1)、API Key + API Secret

(2)、cookie-session认证

这是比较老牌的鉴权方式了，这种鉴权方式有一下特点：

A、为了使后台应用能识别是那个用户发出的请求，只能在后台服务器存储一份用户登陆信息，这份信息也会在相应前端请求时返回给浏览器，前端将其保存为cookie.

B、下次请求时前端发送给后端应用，后端应用就可以识别这个请求是来自那个用户了。

C、cookie内仅包含一个session标识符而诸如用户信息、授权列表等都保存在服务端的session中。

优点：

A、老牌，资料多，语言支持完善。

B、较易于扩展，外部存储session存储方案一斤非常成熟了。(比如：redis)

缺点：

1）性能相于较低：每一个用户经过后端应用认证之后，后端应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

2）与REST风格不匹配。因为它在一个无状态协议里注入了状态。

3）CSRF攻击：因为基于cookie来进行用户识别, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。有兴趣可以看下http://www.uml.org.cn/Test/201508124.asp 。

4）很难跨平台：在移动应用上 session 和 cookie 很难行通，你无法与移动终端共享服务器创建的 session 和 cookie。

(3)、OAuth

(4)、token

简述：token通过一次登陆验证，得到一个鉴权字符串，然后带着这个鉴权字符串进行后续的操作，这样就可以解决每次请求都要带着用户名和密码的问题，而且不用反复使用用户名和密码。

A、Token的优势

token相对于Cookie+Session的有带你，主要有下面两个：

1.1CSTF攻击

1.2、适合移动应用

移动端不支持Cookie，而token只要客户端能够进行存储就能够使用，因此Token在移动端上也具有优势。

1.3、Token的种类

一般来说Token主要有三种：

A、自定义Token：开发者根据业务逻辑自定义的Token

B、JWT：Json Web Token，定义在RFC 7519中的一种Token规范。

C、Oauth2.0:定义在RFC 6750中的一种授权规范，但这其实不是一种Token，只是其中也有用到Token。

(4)、JWT (JSON Web Tokens),是一种规范化的token，

4.1、组成：一个JWT token 是一个字符串，它由三部分组成，头部、载荷与签名，中间用 . 分隔，例如xxxxx.yyyyy.zzzzz

4.1.1头部(header):由两部分组成，令牌和类型(即JWT)和正在使用的签名算法(如RSA).

4.1.2、载荷:公有的载荷，私有的载荷

4.1.3、签名

4.2、使用

JWT的使用有两种方式：

A、加到url中：?token=你token

B、加到Hearder中，建议用这种，因为在https情况下更安全：Authorization:Bearer 你的token

JWT在客户端有三种存储方式：

A、LocalStorage

B、SessionStorage

C、Cookie[不能设置HttpPonly]

4.3、相对于一般的token的优点

无状态

A、JWT常常被用作保护服务端的资源(resource).

B、客户端通常将JWT通过HTTP的Authorization header发送给服务端。

C、服务端使用自己保存的key计算、验证签名以判断该JWT是否可信。

D、在web应用中，别再把JWT当作session使用，绝大多数情况下，传统的cookie-session机制工作的更好。

E、JWT适合一次性的命令认证，颁发一个有效期机端的JWT,即使暴露危险也很小。

F、由于每次操作都会生成新的JWT，因此也没有必要保存JWT，真正实现无状态。

 

转载于:https://my.oschina.net/u/4034553/blog/3063980