关于token鉴权到底是什么?应用场景?

橘子汽水.
  • 34

按我目前的理解,token鉴权一种是服务端生成token后存放在服务器中然后发送给客户端,客户端下次请求时带着这个token。这样使用其实我觉得和cooki+session很相似,安全性也差不多。
还有一种用法是使用用户信息和一定规则加上签名生成token或者说jwt标准那样子的,服务端生成后发送给客户端,服务端不进行存储,下次用户请求时对用户所携带的token进行拆解然后按相同规则生成一个新的token和用户携带来的token进行比较,如果一致就验证通过,这样做确实有效防止了token被篡改的可能,但是token如果被别有用心的人获取不也是也已伪造身份做一些不好的事情吗?
我觉得如果对token进行了固化,那么用起来不和cookie没啥区别的。但是如果不固image.png
这是我在okta上看到的,貌似是个官方?,我也不太懂,我选中的那块它说了令牌位于用户浏览器中那就相当与是固化吗?还有对一次性token的理解,是不固化?还是说用户退出后销毁相应的token?
但是如果是jwt的话还可以用payload设置销毁时间,但是也不能直接进行销毁啊,只能是修改已经固化在本地的token吗

以上都是我自己个人的理解,没有别的意思,看了好些博客仍然对这个token不是很理解,网上的token貌似讲的都一样把我想知道的都没说出来。新手刚入门,求解答。

回复
阅读 898
2 个回答

如果是使用token 最好还是使用jwt 吧,无状态的优势很明显。无并发困扰,无存储风险,劣势就是无法强制失效。这也就是你说的安全性问题,如果一个token长期有效,且服务器无法强制注销,是很危险,不过token 都有有效时间,一般的建议是将有效时间设置的比较短,然后用refresh_token来做补充。当然,如果不嫌麻烦,能接收消耗,你也可以每次访问都刷新。确实和cookie+session的方式很类似,所以有很多把token当cookie用的,不过是存储方式和形式变了,但jwt 和 cookie+session的方式虽然很像,但目的已经变了。

1. COOKIE

cookie是一种“存储协议”,约定了服务端、客户端如何自动化的传输、管理存储在客户端中的数据
你可以用cookie存储任何内容,比如:

  • 身份标识符 (id、token、username等)
  • 业务数据(访问历史、购物车等)

这些数据在符合cookie协议的情况下,在每次请求时自动附加到请求头,提交给服务

2. Token

token 是一个“身份凭据”,用来证明用户是谁,或者证明用户有访问权限。
token 想要顺利使用,需要借助某种协议发送给服务器

3.鉴权

在鉴权这个场景中,token、user_id、user_name是属于同一个概念,即用户标识
这个标识需要发送给服务端,一般2种方式

  1. 存到cookie中,自动发送给服务端 (此处,token和cookie产生了交集
  2. 手动添加到请求头,发送给服务端 (绝大部分的做法,尤其是在app端)

为什么?
如果你了解过cookie的处理机制只好,就知道:
“用户标识符发送给服务端这件事” 这件事情中,直接添加请求头这种方式简单粗暴高效

4.JWT

随着token的应用越来越多,jwt 对token的用法进行统一和扩展,比如增加了签名(防篡改)、过期时间等,总的来说,如果要使用token来进行鉴权的话,建议使用jwt

5. 总结

无论是cookie、session、token,获取将来的其他什么东西,其本质都是一样的:
为了解决HTTP无状态特性下的用户标识(或权限验证),将标识符交给用户,并要求用户每次请求时带上该标识符

只要处理得当,他们的效果没有区别
只不过在“处理”这件事上,我们希望更方面一些罢了

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
你知道吗?

宣传栏