鉴权

最新推荐文章于 2022-05-18 19:04:17 发布

一杯茶一首歌

最新推荐文章于 2022-05-18 19:04:17 发布

阅读量183

点赞数

分类专栏： 03Java开发

本文链接：https://blog.csdn.net/qq_27193479/article/details/103189650

版权

03Java开发专栏收录该内容

6 篇文章 0 订阅

订阅专栏

前后端常见的几种鉴权方式

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验证机制，专门做一个鉴权服务，用它向多个服务的请求进行统一鉴权。