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,真正实现无状态。