本篇文章为你整理了keycloak~JWT没有被持久化（）的详细内容，包含有 keycloak~JWT没有被持久化，希望能帮助你了解 keycloak~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字段

　　以上就是keycloak~JWT没有被持久化（）的详细内容，想要了解更多 keycloak~JWT没有被持久化的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。