1.基于token的认证方式
在大多数使用Web API
的互联网公司中,tokens
是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证
1.无状态、可扩展
2.支持移动设备
3.跨程序调用
4.安全
2.Token的起源
在介绍基于Token
的身份验证的原理与优势之前,不妨先看看之前的认证都是怎么做的。
- 基于服务器的验证
我们都是知道HTTP
协议是无状态的,这种无状态意味着程序需要验证每一次请求,从而辨别客户端的身份。
在这之前,程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session
来完成。
- 基于服务器验证方式暴露的一些问题
1.Seesion
:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。
2.可扩展性:在服务端的内存中使用Seesion
存储登录信息,伴随而来的是可扩展性问题。
3.CORS
(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题。在使用Ajax
抓取另一个域的资源,就可以会出现禁止请求的情况。
4.CSRF
(跨站请求伪造):用户在访问银行网站时,他们很容易受到跨站请求伪造的攻击,并且能够被利用其访问其他的网站。
在这些问题中,可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
3.基于Token的验证原理
基于Token的身份验证是无状态的,我们不将用户信息存在服务器中。这种概念解决了在服务端存储信息时的许多问题。NoSession
意味着你的程序可以根据需要去增减机器,而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
-
用户通过用户名和密码发送请求。
-
服务器端程序验证。
3.服务器端程序返回一个带签名的token
给客户端。
4.客户端储存token
,并且每次访问API
都携带Token
到服务器端的。
5.服务端验证token
,校验成功则返回请求数据,校验失败则返回错误码。
4.时序图表示
使用 Token
和 Refresh Token
的时序图如下:
1)登录
2)业务请求
3)
Token
过期,刷新 Token
上面的时序图中并未提到
Refresh Token
过期怎么办。不过很显然,Refresh Token
既然已经过期,就该要求用户重新登录了。