keycloak~JWT没有被持久化_是因为你对方法论理解不到位

JWT没有被持久化？

• 我们总是说，JWT(json web token)是一个自解释的token，里面有用户相关的信息，它不需要被保存在服务端，降低了服务端的压力；
• 同时有人会说，如果希望验证token的实时在线性，你用JWT怎么实现？
• 有一些人直接会说，把这个JWT保存到redis里就行了，redis里有，它就是在线的...
• 事实上，这些声音对"在线性"的理解不够透彻，在线性因为和浏览器会话有关，应该和session_id有关，而对于keycloak这个框架来说，它有自己的
  session_id，它被称为auth_session_id，它会存储到客户端cookie里，同时它也会放在认证服务器生产的JWT的payload里，在那里叫session_state
• session_state就是一个UUID码，它比jwt要小很多，所以认证服务器把它缓存起来，比起直接缓存JWT大串，压力会小很多

jwt的在线线校验设计

jwt权限刷新方式

keycloak封装的token的核心属性

• exp(Expiration Time) token过期时间戳
• iat(Issued At) token生成时间戳
• jti(jwt id,token_id) token的唯一身份标识,对接token_id或者refresh_token_id，这两个id在服务端会有存储，与它颁发的token里的jti相对应
• iss(Issuer) token的发行机制，kc中的域，例如：https://cas.pkulaw.com/auth/realms/fabao
• aud(Audience) 授权到的客户端，您在kc为用户添加某些客户端角色时，这个用户的token将出现这些客户端
• sub(Subject) 当前用户ID
• typ(Type) 认证方式，例如Bearer
• azp 当前发起认证的客户端client_id
• session_state 当前会话id,浏览器中的AUTH_SESSION_ID和AUTH_SESSION_ID_LEGACY
• acr 如果clientSession通过cookie (SSO)进行身份验证，则使用0，否则为1
• allowed-origins 允许哪种域名使用我们的token
• realm_access 域的权限
• resource_access 客户端（资源）权限，kc允许你为用户依照客户端去授权
• scope 客户端模板，它将一类jwt中的属性进行分类，通过这个scope模块去渲染你的jwt字段