JWT能够干什么,不应该干什么?
2017-11-28 16:20
363 查看
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
At the start of this article, I said that there are good usecases for JWT, but that they're just not suitable as a session mechanism. This still holds true; the usecases where JWT is particularly effective are typically usecases where they are used as a single-use authorization token.
From the JSON Web Token specification:
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. [...] enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
In this context, "claim" can be something like a 'command', a one-time authorization, or basically any other scenario that you can word as:
Hello Server B, Server A told me that I could <claim goes here>, and here's the (cryptographic) proof.
For example, you might run a file-hosting service where the user has to authenticate to download their files, but the files themselves are served by a separate, stateless "download server". In this case, you might want to have your application server (Server A) issue single-use "download tokens", that the client can then use to download the file from a download server (Server B).
When using JWT in this manner, there are a few specific properties:
The tokens are short-lived. They only need to be valid for a few minutes, to allow a client to initiate the download.
The token is only expected to be used once. The application server would issue a new token for every download, so any one token is just used to request a file once, and then thrown away. There's no persistent state, at all.
The application server still uses sessions. It's just the download server that uses tokens to authorize individual downloads, because it doesn't need persistent state.
As you can see here, it's completely reasonable to combine sessions and JWT tokens - they each have their own purpose, and sometimes you need both. Just don't use JWT for persistent, long-lived data.
At the start of this article, I said that there are good usecases for JWT, but that they're just not suitable as a session mechanism. This still holds true; the usecases where JWT is particularly effective are typically usecases where they are used as a single-use authorization token.
From the JSON Web Token specification:
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. [...] enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
In this context, "claim" can be something like a 'command', a one-time authorization, or basically any other scenario that you can word as:
Hello Server B, Server A told me that I could <claim goes here>, and here's the (cryptographic) proof.
For example, you might run a file-hosting service where the user has to authenticate to download their files, but the files themselves are served by a separate, stateless "download server". In this case, you might want to have your application server (Server A) issue single-use "download tokens", that the client can then use to download the file from a download server (Server B).
When using JWT in this manner, there are a few specific properties:
The tokens are short-lived. They only need to be valid for a few minutes, to allow a client to initiate the download.
The token is only expected to be used once. The application server would issue a new token for every download, so any one token is just used to request a file once, and then thrown away. There's no persistent state, at all.
The application server still uses sessions. It's just the download server that uses tokens to authorize individual downloads, because it doesn't need persistent state.
As you can see here, it's completely reasonable to combine sessions and JWT tokens - they each have their own purpose, and sometimes you need both. Just don't use JWT for persistent, long-lived data.
相关文章推荐
- 我的时间能够干什么
- 我们应该学什么
- 第一份工作应该做什么?
- 一个人运气不好怎么办?做什么事能够马上改变运气?
- 登录服务器windows2008出现:远程桌面服务当前正忙,因此无法完成您尝试执行的任务。请在几分钟后重试。其他用户应该仍然能够登录
- [项目管理]项目经理应该做什么——全程建模绩效管理办法执行中出现的偏差之二
- 数据分析师应该干些什么
- PHP应该学什么,如何学好PHP
- 写代码应该用什么字体?
- (第3篇)HDFS是什么?HDFS适合做什么?我们应该怎样操作HDFS系统?
- 如果你的简历上面写“熟悉/了解C#”,那么你就应该能够回答下面的这些基础问
- 初始UML ,我们应该了解什么?
- 面试时应该问些什么问题
- 持续集成:什么应该自动化?
- 策划之痛:策划到底应该做什么?
- 什么时候应该用equals(),什么时候应该用==
- C++ - 头文件(.h)和源文件(.cpp)都应该写些什么
- 转:项目报告应该汇报什么内容?
- 高性能web开发 - 如何加载JS,JS应该放在什么位置?
- 学习.net应该知道什么