前后端常见的几种鉴权方式
https://blog.csdn.net/weixin_34023982/article/details/91647203
- HTTP Basic Authentication
- session-cookie
- Token 验证
- OAuth(开放授权)
Token 验证
使用基于 Token 的身份验证方法,大概的流程是这样的:
- 客户端使用用户名跟密码请求登录 - 服务端收到请求,去验证用户名与密码 - 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端 - 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里 - 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token - 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端返回请求的数据
总的来说就是客户端在首次登陆以后,服务端再次接收http请求的时候,就只认token了,请求只要每次把token带上就行了,服务器端会拦截所有的请求,然后校验token的合法性,合法就放行,不合法就返回401(鉴权失败)。
乍的一看好像和前面的seesion-cookie有点像,seesion-cookie是通过seesionid来作为浏览器和服务端的链接桥梁,而token验证方式貌似是token来起到seesionid的角色。其实这两者差别是很大的。
-
sessionid 他只是一个唯一标识的字符串,服务端是根据这个字符串,来查询在服务器端保持的seesion,这里面才保存着用户的登陆状态。但是token本身就是一种登陆成功凭证,他是在登陆成功后根据某种规则生成的一种信息凭证,他里面本身就保存着用户的登陆状态。服务器端只需要根据定义的规则校验这个token是否合法就行。
-
session-cookie是需要cookie配合的,居然要cookie,那么在http代理客户端的选择上就是只有浏览器了,因为只有浏览器才会去解析请求响应头里面的cookie,然后每次请求再默认带上该域名下的cookie。但是我们知道http代理客户端不只有浏览器,还有原生APP等等,这个时候cookie是不起作用的,或者浏览器端是可以禁止cookie的(虽然可以,但是这基本上是属于吃饱没事干的人干的事)…,但是token 就不一样,他是登陆请求在登陆成功后再请求响应体中返回的信息,客户端在收到响应的时候,可以把他存在本地的cookie,storage,或者内存中,然后再下一次请求的请求头重带上这个token就行了。简单点来说cookie-session机制他限制了客户端的类型,而token验证机制丰富了客户端类型。
-
时效性。session-cookie的sessionid实在登陆的时候生成的而且在登出事时一直不变的,在一定程度上安全就会低,而token是可以在一段时间内动态改变的。
-
可扩展性。token验证本身是比较灵活的,一是token的解决方案有许多,常用的是JWT,二来我们可以基于token验证机制,专门做一个鉴权服务,用它向多个服务的请求进行统一鉴权。
Token鉴权机制
1、用户注册/添加用户,两个参数:userId、password
2、用户登录,登录校验userId和password 是否正确,正确根据userId、password 、时间戳,用MD5不可逆算法生成token。
将userId、token、超时时间存到数据库中,可以存在redis中,并将token返回给客户端。
3、前台在超时时间内再次请求带上userId和token即可进行rest请求,后台校验前台带过来的userId和token是否和后台数据库的匹配,不匹配报错,匹配可重置超时时间,防止用户一直在操作还报超时问题。匹配返回前台需要的数据。
相关博文
基于JWT的Token认证机制(一)
https://blog.csdn.net/why15732625998/article/details/78534711