跨client(web|app|postman|...)登录

从概念上，抽出这四大类，在现实中，用户仅仅只是在访问资源（Resource），用户要去查看报价，查看商品，但是实际上用户是没法直接跟（Resource）一方交互的，因为它是一个Api,所以用户就需要借助一个工具，这个工具统称为client,这个client有可能是APP,WEB,PostMan,
用户看不到API，只能通过图像界面+文字的形式表达出来。所以用户就会跟client说：“你（client）去向它（Resource）请求，并且翻译给我(用户)；” 但是呢，Resource说：我为了安全性的考虑，我凭什么相信你（client）？你要我给你资源我就得给你吗？

切换到两个问题：我凭什么相信你（client）,我凭什么相信是你？

我们做的是全网通的系统。（app,web,...统一单点登录）。
现在切换到问题，Resource说：不行，这样很不安全，我啥也不认，我只认一个令牌（token）,就类似于去找政府办事，他说你得给我开个证明，这个证明就是这个令牌，那开证明的事归谁开呢？相关的授权部分开。好了，现在我们把相关的授权部门放到IDS上，假设现在你要去买火车票，售货员说：你啥都没带，我怎么给你卖火车票呢？现在都是实名制了。你得证明你是谁（身份）。

这个时候就得去办理身份证，办理身份证后，还不行，因为我这个是铁路售票系统，你拿了身份证就可以直接安检了？没那么容易吧？铁路只认它们自己的票据（火车票），所以你得去相应的购买窗口买一张火车票才能通行。然后铁路售票系统就说：行了，带上你的身份证+火车票你就可以通行我们这个口进行安检了。这个购票窗口相当于client其中的一个入口，client就相当于综合售票大厅，你在这里既可以办理身份证，又可以买票。

这个时候你会问，我直接用我的用户名和密码去置换不行么？非得先去办理身份证。因为如果是这样的话，会出现问题：当我们Resource Api有十个或者多个的时候，就会把用户名和密码同时得进行校验在十个或者多个的Api上，只要稍微有点问题的话，你的密码在十个api或者多个api上就全网公开了，如果是用传统的颁发cookie的过程，就需要在十个api上都进行颁发，就类似于开发十个微服务，十个都需要进行写登陆授权，所以我们就需要在单个的IDS上进行登录授权，如果只是泄漏的话，只是保证了是一个泄露了，其他的api都不需要管，只修改这个api就行了，其它的api不负责这个事。如果是在多个的话，每个人写的代码不一样。

而token是有有效期的，token只能用一段时间就会过期了。
过期的话就需要重新去获取请求新的token。