关于jwt:浅谈一下前后端鉴权方式-^^

浅谈一下前后端鉴权形式 ^.^尽管自己当初从事前端开发,然而之前始终是 PHP 全栈,所以对前后端鉴权机制也有肯定的理解,就找些材料简略记录一下吧。(瞎掰扯~)常见鉴权机制HTTP 是无状态的协定(对于事务处理没有记忆能力,每次客户端和服务端会话实现时,服务端不会保留任何会话信息。):每个申请都是齐全独立的,服务端无奈确认以后访问者的身份信息,无奈分辨上一次的申请发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪(晓得是谁在拜访我),就必须被动的去保护一个状态,这个状态用于告知服务端前后两个申请是否来自同一浏览器,由此产生了很多种鉴权形式。HTTP Basic AuthenticationSession-CookieTokenOAuth另外咱们要留神辨别 Authentication 与 Authrization,一个是认证一个是受权。Authentication 是为了验证你是不是自己,而 Authrization 是为了验证你有没有做某件事情的权限。咱们别离举三个例子来阐明三种状况让大家对认证和受权的关系有更好的了解。只认证不受权 只是登录利用,并不进行其余操作,这时候不须要受权只进行认证。既认证又受权 咱们应用第三方利用登录的时候,既输出了第三方利用的账号密码来认证,又受权了本利用读取第三方登录利用曾经注册了的个人信息数据等。不认证只受权 咱们点开小程序时,须要获取个人信息,这种时候相当于只受权数据给小程序,并未进行认证,毕竟在利用外部应用小程序,很少有须要再登录认证这种操作。各鉴权机制流程与原理 一旦波及认证受权,必须要思考的一个问题就是状态治理。所谓的状态治理就是说咱们在进行登录之后的一段时间里,不心愿每次拜访它都须要从新登录。所以开发者必须要思考怎么样放弃用户的登录状态以及设置生效工夫。而这个过程须要前后端通力合作来实现。 上面就来简略谈一下几种常见的认证和受权形式的流程与原理,自己瞎掰扯,欢送大佬指导。HTTP Basic Authentication 这种受权形式是浏览器恪守 HTTP 协定实现的根本受权形式,HTTP 协定进行通信的过程中定义了根本认证容许 HTTP 服务器对客户端进行用户身份证的办法。 根本流程发送申请:客户端向服务器申请数据,申请的内容可能是一个网页或者是一个 ajax 异步申请,此时假如客户端尚未被验证(服务器验证并判断是否返回 401),则客户端提供如下申请至服务器。Get /index.html HTTP/1.0 Host: www.google.com服务器返回 401:服务器向客户端发送验证申请代码 401,WWW-Authenticate: Basic realm="google.com" 这句话是要害,如果没有客户端不会弹出用户名和明码输出界面,服务器返回的数据大抵如下。HTTP/1.0 401 Unauthorised Server: SokEvo/1.0 WWW-Authenticate: Basic realm="google.com"Content-Type: text/html Content-Length: xxx客户端弹出窗口:当合乎 http1.0 或 1.1 标准的客户端收到 401 返回值时,将自动弹出一个登录窗口,要求用户输出用户名和明码。 这个时候申请时属于 pending 状态,当用户输出用户名明码的时候客户端会再次发送申请头带 Authorization 的申请。用户输出用户名和明码:输出明码后,点击提交会将用户名及明码以 Base64 加密形式加密,并将密文放入前一条申请信息中,则客户端发送的第一条申请信息则变成如下内容。Get /index.html HTTP/1.0 Host: www.google.comAuthorization: Basic xxxxxxx(base64 密文)// 加密过程是浏览器默认的行为,不须要咱们人为加密,咱们只须要输出用户名明码即可。服务端解密:服务器收到上述申请信息后,将 Authorization 字段后的用户信息取出并解密,将解密后的用户名及明码与用户数据库进行比拟验证,如用户名及明码正确,服务器则依据申请,将所申请资源发送给客户端。 ...

September 28, 2023 · 3 min · jiezi

关于jwt:gozero-jwt-鉴权快速实战

后面咱们分享了 go-zero 的疾速实战以及日志组件的分析,本次咱们来实战应用 go-zero jwt 鉴权 本次文章次要是分享对于 go-zero 中 jwt 的应用形式,会以一个 demo 的形式来进行实战,对于应用 goctl 工具以及装置细节就不在赘述,有需要的话能够查看: 官网本次文章次要分为如下几个局部: Jwt 的简略介绍<!----> Go-zero 中应用 jwt 实战Jwt 的简略介绍对于 jwt 鉴权的细节和原理,感兴趣的敌人能够查看历史文章:JWT身份认证(附带源码解说) | GO主题月 那么咱们如何辨认什么时候须要应用 jwt 呢? 用于受权例如某个零碎通过例如账号密码登录之后,后盾会生成一个 jwt,这个用户在这个零碎之后的任何操作,都会去校验这个 jwt,就不须要用户操作系统内其余模块的时候,还去进行一次登录 当然,这是须要咱们做好设定,这个 jwt 针对哪一些路由能够应用,从而容许用户拜访该令牌容许的路由,服务和资源 用于信息替换因为 jwt 能够与各方进行平安的传输,外部应用了签名算法,公钥加密,私钥解密,而且 jwt 的数据各种中有标头,有效载荷,以及其余的签发工夫,过期工夫,颁发人等等,能够用来校验信息是否被篡改了 Go-zero 中应用 jwt 实战话不多说,咱们就来开始实战吧,先来给本人提一个需要: 需要同学们平时去图书馆,都是须要登录本人的账号,才能够进入零碎查问书籍余量的<!----> 那么咱们就来实现一下,用账号密码登录图书零碎,并生成一个 jwt,后续该用户进行书籍查问的时候,就能够间接应用 jwt 来进行鉴权剖析那么,根据上述需要,显然,咱们会应用到数据库,本次这里咱们依然应用 mysql 进行演示,并且会波及到用户表和图书表 咱们能够当初创立一下这两张表 user tableuser.sql CREATE TABLE `user`( `stu_id` varchar(255) NOT NULL COMMENT 'stu_id', `name` varchar(255) NOT NULL COMMENT 'name', `password` varchar(255) NOT NULL COMMENT 'password', `gender` varchar(255) NOT NULL COMMENT 'gender', PRIMARY KEY(`stu_id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;stu_id学号name姓名password明码gender性别book tablebook.sql ...

September 2, 2023 · 3 min · jiezi

关于jwt:实践篇教你玩转JWT认证从一个优惠券聊起-京东云技术团队

引言最近面试过程中,无心中跟候选人聊到了JWT相干的货色,也就联想到我本人对于JWT落地过的那些我的项目。 对于JWT,能够说是分布式系统下的一个利器,我在我的很多我的项目实际中,认证零碎的第一抉择都是JWT。它的劣势会让你骑虎难下,就像你领优惠券一样。 大家回顾一下一个场景,如果你和你的女朋友想吃某江家的烤鱼了,你会怎么做呢? 传统的时代,我想场景是这样的:咱们走进一家某江家餐厅,会被服务员疏导一个桌子,而后咱们开始点餐,服务原会记录咱们点餐信息,而后在送到后厨去。这个过程中,那个餐桌就相当于session,而咱们的点餐信息回记录到这个session之中,而后送到后厨。这个是一个典型的基于session的认证过程。但咱们也发现了它的弊病,就是基于session的这种认证,对服务器强依赖,而且信息都是存储在服务器之上,灵活性和扩展性大大降低。 而互联网时代,公众点评、美团、饿了么给了咱们另一个抉择,咱们可能第一工夫会在这些平台上搜寻江边城外的优惠券,这个优惠券中可能会形容着两人实惠套餐明细。这张优惠券就是咱们的 JWT,咱们能够在任何一家有参加优惠活动的餐厅应用这张优惠券,而不用被限度在同一家餐厅。同时这张优惠券中间接记录了咱们的点餐明细,等咱们到了餐厅,只须要将优惠券二维码告知服务员,服务员就会给咱们端上咱们想要的食物。 好了,以上只是一个小例子,其实只是想阐明一下JWT相较于传统的基于session的认证框架的劣势。 JWT 的劣势在于它能够跨域、跨服务器应用,而 Session 则只能在本域名下应用。而且,JWT 不须要在服务端保留用户的信息,只须要在客户端保留即可,这加重了服务端的累赘。 这一点在分布式架构下劣势还是很显著的。 什么是JWT说了这么多,如何定义JWT呢? JWT(JSON Web Token)是一种用于在网络应用中进行身份验证的凋谢规范(RFC7519)。它能够平安地在用户和服务器之间传输信息,因为它应用数字签名来验证数据的完整性和真实性。 JWT蕴含三个局部:头部、载荷和签名。头部蕴含算法和类型信息,载荷蕴含用户的信息,签名用于验证数据的完整性和真实性。 额定说一下poload,也就是负荷局部,这块是jwt的外围模块,它外部包含一些申明(claims)。申明由三个类型组成: Registered Claims:这是预约义的申明名称,次要包含以下几种: iss:Token 发行者sub:Token 主题aud:Token的受众exp:Token 过期工夫iat:Token发行工夫jti:Token惟一标识符Public Claims:公共申明是本人定义的申明名称,以防止抵触。 Private Claims:公有申明与公共申明相似,不同之处在于它是用于在单方之间共享信息的。 当用户登录时,服务器将生成一个JWT,并将其作为响应返回给客户端。客户端将在后续的申请中发送此JWT。服务器将应用雷同的密钥验证JWT的签名,并从载荷中获取用户信息。如果签名验证通过并且用户信息无效,则服务器将容许申请持续进行。 JWT长处JWT长处如果咱们零碎的总结一下, 如下: 跨语言和平台:JWT是基于JSON规范的,因而能够在不同的编程语言和平台之间进行替换和应用。无状态:因为JWT蕴含所有必要的信息,服务器不须要在每个申请中存储任何会话数据,因而能够轻松地进行负载平衡。安全性:JWT应用数字签名来验证数据的完整性和真实性,因而能够避免数据被篡改或伪造。可扩展性:JWT能够蕴含任何用户信息,因而能够轻松地扩大到其余应用程序中。一个基于JWT认证的计划我将举一个我理论业务落地的一个例子。 我的业务场景中个别都会有一个业务网关,该网关的外围性能就是鉴权和上线文转换。用户申请会将JWT字符串存与header之中,而后到网关后进行JWT解析,解析后的上下文信息,会转变成明文K-V的形式在此存于header之中,供零碎外部各个微服务之间相互调用时提供明文上下文信息。具体时序图如下: 基于Spring security的JWT实际JWT原理很简略,当然,你能够齐全本人实现JWT的全流程,然而,理论中,咱们个别不须要这么干,因为有很多成熟和好用的轮子提供给咱们,而且封装性和安全性也远比本人匆忙的封装一个简略的JWT来的高。 如果是基于学习JWT,我是倡议大家本人手写一个demo的,然而如果重实际的角度触发,咱们齐全能够应用Spring Security提供的JWT组件,来高效疾速的实现一个稳定性和安全性都十分高的JWT认证框架。 以下是我基于我的业务理论状况,依据保密性要求,简化了的JWT实际代码。也算是抛砖引玉,心愿能够给大家在业务场景中使用JWT做一个参考。 maven依赖首先,咱们须要增加以下依赖到pom.xml文件中: <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-security</artifactId></dependency><dependency><groupId>io.jsonwebtoken</groupId><artifactId>jjwt</artifactId><version>0.9.1</version></dependency>JWT工具类封装而后,咱们能够创立一个JwtTokenUtil类来生成和验证JWT令牌: import io.jsonwebtoken.Claims;import io.jsonwebtoken.Jwts;import io.jsonwebtoken.SignatureAlgorithm;import org.springframework.beans.factory.annotation.Value;import org.springframework.security.core.userdetails.UserDetails;import org.springframework.stereotype.Component;import java.util.Date;import java.util.HashMap;import java.util.Map;import java.util.function.Function;@Componentpublic class JwtTokenUtil { private static final long JWT_TOKEN_VALIDITY = 5 * 60 * 60; @Value("${jwt.secret}") private String secret; public String generateToken(UserDetails userDetails) { Map<String, Object> claims = newHashMap <>(); return createToken(claims, userDetails.getUsername()); } private String createToken(Map<String, Object> claims, String subject) { Date now = new Date(); Date expiration = new Date(now.getTime() + JWT_TOKEN_VALIDITY * 1000); return Jwts.builder() .setClaims(claims) .setSubject(subject) .setIssuedAt(now) .setExpiration(expiration) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public boolean validateToken(String token, UserDetails userDetails) { final String username = extractUsername(token); return (username.equals(userDetails.getUsername()) && !isTokenExpired(token)); } private boolean isTokenExpired(String token) { return extractExpiration(token).before(new Date()); } public String extractUsername(String token) { return extractClaim(token, Claims::getSubject); } public Date extractExpiration(String token) { return extractClaim(token, Claims::getExpiration); } private <T> T extractClaim(String token, Function<Claims, T> claimsResolver) { final Claims claims = extractAllClaims(token); return claimsResolver.apply(claims); } private Claims extractAllClaims(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); }}在这个实现中,咱们应用了jjwt库来创立和解析JWT令牌。咱们定义了以下办法: ...

May 19, 2023 · 3 min · jiezi

关于jwt:jwt身份认证概述

JWT全称JSON Web Token 利用流程客户端应用用户名和明码申请登录,服务端收到申请验证用户名和明码正确后,后端通过JWT机制,将用户数据作为JWT的Payload,同时在后面拼接上一个JWT Header之后进行Base64编码,并进行签名,生成一个token,格局为header.payload.signature,返回给客户端客户端后续的每次申请都须要携带token,携带在HTTP Header Authorization中后端拿到客户端传递的token后,进行解密验证身份,验证其有效性,查看签名是否正确,是否过期,最初解析出JWT Token中的用户信息长处无状态,token机制在服务端不须要存储session信息,因为token本身蕴含了所有登录用户的信息,所以能够加重服务端压力分布式敌对,因为session须要固定保留在一个中央,如果保留在本机,分布式系统中认证会生效,如果采纳redis等对立保留session,零碎复杂性会减少反对跨域拜访,跨域后不会存在信息失落问题CDN敌对,能够通过内容散发网络申请服务端的所有材料挪动端敌对,当客户端是非浏览器平台时,cookie是不被反对的,此时采纳token认证形式会简略很多无需思考CSRF(Cross Site Request Forgery跨站点申请伪造),token是开发者为了防备csrf而特地设计的令牌,浏览器不会主动增加到headers里,攻击者也无法访问用户的token,所以攻击者提交的表单无奈通过服务器认证,也就无奈造成攻打 CSRF简述 在一个浏览器中关上了两个标签页,其中一个页面通过窃取另一个页面的 cookie 来发送伪造的申请,因为cookie 是随着浏览器申请主动发送到服务端的,这个是CSRF攻打胜利的外围起因session认证实质须要依赖Cookie,如果cookie被截获,用户很容易受到跨站申请伪造攻打CSRF无奈间接窃取到用户的Cookie,header,仅仅是冒用Cookie毛病不可控,因为JWT无状态,想要在JWT 有效期内废除一个JWT或者更改它的权限的话,并不会立刻失效,通常须要等到有效期过后才能够,如果要防止这个问题,须要把JWT存入redis等缓存,JWT生效的时候就删除这个JWT,每次验证的时候查问一下JWT在不在redis,然而这样就减少了老本和零碎复杂度token续签不不便,JWT自身payload参数当中携带exp参数示意过期工夫,payload批改之后签名也须要批改,所以须要从新生成一个JWTJWT令牌个别会比拟长,如果是性能极度敏感的话须要在意这一点组成JWT生成的Token由三局部组成:header.payload.signature,艰深地说,JWT的实质是一个字符串,将用户信息保留到一个Json字符串中,而后进行编码后失去一个JWT token,并且这个JWT token带有签名信息,接管后能够校验是否被篡改,所以能够用于在各方之间平安地将信息作为Json对象传输 header alg:指定signature采纳的加密算法,默认是HS256(HMAC SHA256),对称加密(加密和解密的密钥雷同)typ:固定值,通常是JWT通常值是{"alg": "HS256", "typ": "JWT"}, 通过base64Url算法进行编码之后进行拼接payload 用户id和name默认携带iat,令牌签发工夫(工夫戳)exp设置令牌过期工夫参数个别模式如下,通过base64Url算法进行编码与header进行拼接,默认状况下JWT是未加密的,因为只是采纳base64算法,拿到JWT字符串后能够转换回本来的JSON数据,任何人都能够解读其内容,因而不要构建隐衷信息字段,比方用户的明码肯定不能保留到JWT中,JWT只是适宜在网络中传输一些非敏感的信息,要传递一些敏感数据的话须要应用一些AES或者其余类型的算法,尽量加上一些salt进行加密payload { "sub": "1234567890", "name": "Helen", "admin": true}signature 设置一个secretKey,通过将前两个后果合并后进行HS256算法,signature = HS256(base64Url(header)+'.'+base64Url(payload),secretKey)secreKey肯定不能裸露,因为能够颁发token,也能够解密跨域资源共享是一种基于 HTTP头的机制,该机制次要是为了防止跨站脚本攻打而存在 理论网站开发过程当中须要从A网站拜访到另外一个网站B,就须要通过容许服务器标示除了它本人以外的其余源(域、协定或端口),使得浏览器容许这些源拜访加载本人的资源,服务器须要返回一个HTTP Header Access-Control-Allow-Origin: * 表明,该资源能够被任意外源拜访,这样浏览器才会失常加载返回的数据 然而当携带cookie进行拜访的时候就不能返回一个Header头示意容许被任意外源拜访 服务器不能将 Access-Control-Allow-Origin 的值设为通配符“*”,而应将其设置为特定的域,如:Access-Control-Allow-Origin: https://example.com,如果值被设置为*,申请会失败,如歌设置为具体的域申请胜利服务器不能将 Access-Control-Allow-Headers 的值设为通配符“*”,而应将其设置为标头名称的列表,如:Access-Control-Allow-Headers: X-PINGOTHER, Content-Type服务器不能将 Access-Control-Allow-Methods 的值设为通配符“*”,而应将其设置为特定申请办法名称的列表,如:Access-Control-Allow-Methods: POST, GET详情参考Mozilla对跨域资源共享的定义 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CORSpython实现依赖我的项目pyjwt https://github.com/jpadilla/pyjwt装置 $ pip install pyjwt应用 >>> import jwt>>> encoded = jwt.encode({"some": "payload"}, "secret", algorithm="HS256")>>> print(encoded)eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzb21lIjoicGF5bG9hZCJ9.4twFt5NiznN84AWoo1d7KO1T_yoc0Z6XOpOVswacPZg>>> jwt.decode(encoded, "secret", algorithms=["HS256"]){'some': 'payload'}参考浏览掘金-JWT与Token详解 ...

April 27, 2023 · 1 min · jiezi

关于jwt:浅析使用-JWT-的正确姿势

浅析应用 JWT 的正确姿态在很长的一段时间里,我都没有正确的应用 jwt,意识到这个问题之后,把我最实在的思考和总结拿进去和大家分享下,欢送一起探讨 现状先说下我以前是怎么应用的: 登录胜利后,将 userId 放进 payload 生成 jwt(有效期 8 小时),而后把 jwt 发送到前端,前端存储下来前端每一次拜访 API 需在 header 中携带 jwt后端先解析 jwt,拿到 userId 后,数据库查问此用户的权限列表(用户-角色-权限)拿到用户的权限列表后,和以后接口所需的权限进行匹配,匹配胜利返回数据,失败返回 401jwt 规范先来查查规范是怎么样的,首先参考了jwt.io上面对应用场景的阐明: Authorization 受权Information Exchange 信息替换对于下面的信息,我集体的了解是两个方面: 容许用户拜访路由、服务和资源,在我这里就是接口所需的权限,也能够 SSO 登录,我这里目前不须要能够确定以后用户的身份,在我这里就是 userId 了优化当初的用法有以下缺点: 每次调用接口都须要进行数据库查问权限(用户-角色-权限),浪费资源登录胜利 8 小时后,即便用户始终在不停的应用零碎,但 jwt 还是会生效,须要从新登录第一点好说,把权限列表也放进 payload,解析结束间接和接口所需权限进行比照。 第二点,把有效期缩短到一个星期,一个月?然而依然会产生正在用着用着 jwt 就生效了,须要从新登录的状况,工夫设置的太长也不平安,因为 jwt 自身就是无状态的,而且权限变更了怎么办,难道要等很久才失效吗,这么看来必须要刷新 jwt 了。 对应的优化点就来了: 把权限列表放进 payload,不必每次都去数据库查问让用户无感的刷新 jwt刷新 jwt 计划这里参考了 stackoverflow 下面的探讨: jwt-refresh-token-flowJWT (JSON Web Token) automatic prolongation of expiration而后我确定了我的刷新流程: 登录胜利后颁发两个 token:accessToken 有效期 1 小时,refreshToken 有效期 1 天accessToken 生效后返回 401,前端通过 refreshToken 获取新的 accessToken 和新的 refreshTokenrefreshToken 生效后返回 403,须要从新登录也就是说,登录胜利后,在 refreshToken 有效期内,都能够持续操作,并且顺延有效期,再也不会呈现用着用着忽然须要从新登录的状况了。这俩有效期能够自行调整,我这里思考的是 accessToken 最好不能太长,不然调整权限后失效期太短。 ...

August 4, 2022 · 2 min · jiezi

关于jwt:实战模拟│JWT-登录认证

Token 认证流程作为目前最风行的跨域认证解决方案,JWT(JSON Web Token) 深受开发者的青睐,次要流程如下:客户端发送账号和明码申请登录服务端收到申请,验证账号密码是否通过验证胜利后,服务端会生成惟一的 token,并将其返回给客户端客户端承受到 token,将其存储在 cookie 或者 localStroge 中之后每一次客户端向服务端发送申请,都会通过 cookie 或者header 携带该 token服务端验证 token 的有效性,通过才返回响应的数据 Token 认证长处反对跨域拜访:Cookie 是不容许跨域拜访的,这一点对 Token 机制是不存在的,前提是传输的用户认证信息通过 HTTP 头传输无状态: Token 机制在服务端不须要存储 session 信息,因为 Token 本身蕴含了所有登录用户的信息,只须要在客户端的 cookie 或本地介质存储状态信息适用性更广: 只有是反对 http 协定的客户端,就能够应用 token 认证。无需思考CSRF: 因为不再依赖 cookie,所以采纳 token 认证形式不会产生 CSRF,所以也就无需思考 CSRF 的进攻 JWT 构造一个 JWT 实际上就是一个字符串,它由三局部组成:头部、载荷与签名。两头用点 . 分隔成三个局部。留神 JWT 外部是没有换行的。 头部 / headerheader 由两局部组成: token 的类型 JWT 和算法名称:HMAC、SHA256、RSA{ "alg": "HS256", "typ": "JWT"} 载荷 / PayloadPayload 局部也是一个 JSON 对象,用来寄存理论须要传递的数据。JWT 指定七个默认字段供选择。除了默认字段之外,你齐全能够增加本人想要的任何字段,个别用户登录胜利后,就将用户信息寄存在这里iss:发行人exp:到期工夫sub:主题aud:用户nbf:在此之前不可用iat:公布工夫jti:JWT ID用于标识该JWT{ "iss": "xxxxxxx", "sub": "xxxxxxx", "aud": "xxxxxxx", "user": [ 'username': '极客飞兔', 'gender': 1, 'nickname': '飞兔小哥' ] } 签名 / Signature签名局部是对下面的 头部、载荷 两局部数据进行的数据签名为了保证数据不被篡改,则须要指定一个密钥,而这个密钥个别只有你晓得,并且寄存在服务端生成签名的代码个别如下:// 其中secret 是密钥String signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) JWT 根本应用客户端收到服务器返回的 JWT,能够贮存在 Cookie 外面, 也能够贮存在 localStorage而后 客户端每次与服务器通信,都要带上这个 JWT把 JWT 保留在 Cookie 外面发送申请,这样不能跨域更好的做法是放在 HTTP 申请的头信息 Authorization 字段外面fetch('license/login', { headers: { 'Authorization': 'X-TOKEN' + token }}) 实战:应用 JWT 登录认证这里应用 ThinkPHP6 整合 JWT 登录认证进行实战模仿 装置 JWT 扩大composer require firebase/php-jwt 封装生成 JWT 和解密办法<?php/** * Desc: JWT认证 * Author: autofelix * Time: 2022/07/04 */namespace app\services;use app\Helper;use Firebase\JWT\JWT;use Firebase\JWT\Key;class JwtService{ protected $salt; public function __construct() { //从配置信息这种或取惟一字符串,你能够轻易写比方md5('token') $this->salt = config('jwt.salt') || "autofelix"; } // jwt生成 public function generateToken($user) { $data = array( "iss" => 'autofelix', //签发者 能够为空 "aud" => 'autofelix', //面象的用户,能够为空 "iat" => Helper::getTimestamp(), //签发工夫 "nbf" => Helper::getTimestamp(), //立马失效 "exp" => Helper::getTimestamp() + 7200, //token 过期工夫 两小时 "user" => [ // 记录用户信息 'id' => $user->id, 'username' => $user->username, 'truename' => $user->truename, 'phone' => $user->phone, 'email' => $user->email, 'role_id' => $user->role_id ] ); $jwt = JWT::encode($data, md5($this->salt), 'HS256'); return $jwt; } // jwt解密 public function chekToken($token) { JWT::$leeway = 60; //以后工夫减去60,把工夫留点余地 $decoded = JWT::decode($token, new Key(md5($this->salt), 'HS256')); return $decoded; }} 用户登录后,生成 JWT 标识<?phpdeclare (strict_types=1);namespace app\controller;use think\Request;use app\ResponseCode;use app\Helper;use app\model\User as UserModel;use app\services\JwtService;class License{ public function login(Request $request) { $data = $request->only(['username', 'password', 'code']); // ....进行验证的相干逻辑... $user = UserModel::where('username', $data['username'])->find(); // 验证通过生成 JWT, 返回给前端保留 $token = (new JwtService())->generateToken($user); return json([ 'code' => ResponseCode::SUCCESS, 'message' => '登录胜利', 'data' => [ 'token' => $token ] ]); }} 中间件验证用户是否登录在 middleware.php 注册中间件<?php// 全局中间件定义文件return [ // ...其余中间件 // JWT验证 \app\middleware\Auth::class];注册中间件后,在权限验证中间件中欠缺验证逻辑<?phpdeclare (strict_types=1);namespace app\middleware;use app\ResponseCode;use app\services\JwtService;class Auth{ private $router_white_list = ['login']; public function handle($request, \Closure $next) { if (!in_array($request->pathinfo(), $this->router_white_list)) { $token = $request->header('token'); try { // jwt 验证 $jwt = (new JwtService())->chekToken($token); } catch (\Throwable $e) { return json([ 'code' => ResponseCode::ERROR, 'msg' => 'Token验证失败' ]); } $request->user = $jwt->user; } return $next($request); }}

July 4, 2022 · 2 min · jiezi

关于jwt:jwt生成token和token解析基础

1.jwt构造jwt生成到客户端(浏览器)的token蕴含"."离开的三个局部: header(Base64Url编码过的)payload(Base64Url编码过的)signature形如:xxxxx.yyyyy.zzzzz 1.1 例子:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiYW5keSIsImV4cCI6MTY1NTg5NzEwMCwiYWdlIjozMH0.32hfc-oBxGg2Lgk3QR48HCbadsbOfCUxexw9aiQ_FQk拆为3局部: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.(header)eyJuYW1lIjoiYW5keSIsImV4cCI6MTY1NTg5NzEwMCwiYWdlIjozMH0.(payload)32hfc-oBxGg2Lgk3QR48HCbadsbOfCUxexw9aiQ_FQk(signature)2.header+payload+signature介绍2.1 header下面的header局部:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9base64Url解码后: { "typ": "JWT", "alg": "HS256"}通常阐明token的类型、生成token所应用的的算法 The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.2.2 Payload下面的Payload局部:eyJuYW1lIjoiYW5keSIsImV4cCI6MTY1NTg5NzEwMCwiYWdlIjozMH0base64Url解码后: { "name": "andy", "exp": 1655897100, "age": 30}通常是要客户端申请时带货的内容(比方用户名,比方是否是管理员等,server端生成的时候能够定义内容,模式如map) The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.2.3 Signature下面的Signature局部:32hfc-oBxGg2Lgk3QR48HCbadsbOfCUxexw9aiQ_FQk它是用来验签的, 验证是否被客户端批改过,它的生成逻辑如下:就是应用header局部的base64Url、payload局部的base64Url局部、小圆点、以及你的私钥明码,应用指定的算法生成的;因为有明码, 所以是平安的,这也是明码要爱护好的起因。 ...

June 22, 2022 · 1 min · jiezi

关于jwt:一文带你搞懂-JWT-常见概念-优缺陷

一文带你搞懂 JWT 常见概念 & 优缺点JWT 的劣势相比于 Session 认证的形式来说,使用 JWT 进行身份认证次要有上面 4 个劣势。 无状态JWT 自身蕴含了身份考据所需要的所有信息,因此,咱们的服务器不需要存储 Session 信息。这显然减少了零碎的可用性和伸缩性,大大加重了服务端的压力。不过,也正是因为 JWT 的无状态,也导致了它最大的缺点:不可控!就比方说,咱们想要在 JWT 有效期内废除一个 JWT 或者更改它的权限的话,并不会立即失效,通常需要等到有效期过后才可能。再比方说,当用户 Logout 的话,JWT 也还无效。除非,咱们在后端减少额定的处理逻辑比如将生效的 JWT 存储起来,后端先考据 JWT 是否无效再进行处理。具体的解决办法,咱们会在前面的内容中粗疏介绍到,这里只是简略提一下。 无效避免了 CSRF 攻打CSRF(Cross Site Request Forgery) 一般被翻译为 跨站请求伪造,属于网络攻击领域范畴。相比于 SQL 脚本注入、XSS 等安全攻击方式,CSRF 的知名度并没有它们高。然而,它的确是咱们开发零碎时必须要考虑的安全隐患。就连业内技术标杆 Google 的产品 Gmail 也曾在 2007 年的时候爆出过 CSRF 漏洞,这给 Gmail 的用户造成了很大的损失。 那么究竟什么是跨站请求伪造呢? 简略来说就是用你的身份去做一些不好的事件(发送一些对你不敌对的请求比如恶意转账)。举个简略的例子:小壮登录了某网上银行,他来到了网上银行的帖子区,看到一个帖子上面有一个链接写着“迷信理财,年盈利率过万”,小壮好奇的点开了这个链接,后果发现自己的账户少了 10000 元。这是这么回事呢?原来黑客在链接中藏了一个请求,这个请求间接利用小壮的身份给银行发送了一个转账请求,也就是通过你的 Cookie 向银行收回请求。 CSRF 攻打需要依赖 Cookie ,Session 认证中 Cookie 中的 SessionID 是由阅读器发送到服务端的,只需收回请求,Cookie 就会被携带。借助这个个性,即使黑客无奈获取你的 SessionID,只需让你正点攻打链接,就可能达到攻打成果。另外,并不是必须点击链接才可能达到攻打成果,很多时候,只需你打开了某个页面,CSRF 攻打就会发生。 ...

June 21, 2022 · 2 min · jiezi

关于jwt:虾皮二面什么是-JWT-如何基于-JWT-进行身份验证

分享一下群友面试虾皮遇到的对于 JWT 的面试真题。 相干面试题如下: 什么是 JWT?为什么要用 JWT?JWT 由哪些局部组成?如何基于 JWT 进行身份验证?JWT 如何避免 Token 被篡改?如何增强 JWT 的安全性?如何让 Token 生效?......什么是 JWT?JWT (JSON Web Token) 是目前最风行的跨域认证解决方案,是一种基于 Token 的认证受权机制。从 JWT 的全称能够看出,JWT 自身也是 Token,一种规范化之后的 JSON 构造的 Token。 Token 本身蕴含了身份验证所须要的所有信息,因而,咱们的服务器不须要存储 Session 信息。这显然减少了零碎的可用性和伸缩性,大大加重了服务端的压力。 能够看出,JWT 更合乎设计 RESTful API 时的「Stateless(无状态)」准则 。 并且, 应用 Token 认证能够无效防止 CSRF 攻打,因为 Token 个别是存在在 localStorage 中,应用 JWT 进行身份验证的过程中是不会波及到 Cookie 的。 我在 JWT 优缺点剖析[1]这篇文章中有具体介绍到应用 JWT 做身份认证的劣势和劣势。 上面是 RFC 7519[2] 对 JWT 做的较为正式的定义。 JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. ——JSON Web Token (JWT)[3]JWT 由哪些局部组成?JWT 实质上就是一组字串,通过(.)切分成三个为 Base64 编码的局部: ...

May 30, 2022 · 2 min · jiezi

关于jwt:如何使用jwt-完成注销退出登录功能

原文 神奇的 JSON Web Tokens(JWT)JSON Web Tokens (JWT) 是一种无状态解决用户身份验证的办法。 什么意思? JWT帮忙建设认证机制而不将身份验证状态存储在任何存储中,无论是会话内存还是数据库,因而, 当检查用户的身份验证状态时,不须要拜访会话内存或执行数据库查问。相同, 依据你抉择的用户payload生成token 并在客户端的申请中应用它来标识服务器上的用户 因而,基本上,每当创立token时,就能够永远应用它,或者直到它过期为止。 JWT生成器能够在生成的时候有一个指定过期工夫的选项。 不过你想让曾经生成的token生效该怎么办呢?当用户登记或者更改明码的时候你该做些什么呢 登记通常在应用JWT做身份验证时客户端将token贮存在某个中央,并将附加到每个须要身份验证的申请上,所以登记的第一件事就是删除贮存在客户端上的token(例如 浏览器本地贮存)在这种状况下客户端没有了token申请须要认证的接口天然会失去未认证的响应。不过这就够了吗?这个是防小人不防君子的做法实际上在登记之前通过一些伎俩将token拿到手在登记后仍然能够应用!不信的的话能够本人尝试下。让咱们从后盾登记token,你可能会说桥豆麻袋这对于jwt来说并不是那么简略,你并不能像删除cookie和session那样来删除token。 实际上,JWT的目标与session不同,不可能强制删除或生效曾经生成的token。 Token 过期是的 Token 能够设置过期。在生成token时能够指定过期工夫,你能够在无效的paylaod中加上exp字段就像这样: { "sub": "1234567890", "name": "John Doe", "iat": 1516234022, "exp": 1516239022}exp 字段为工夫戳,这里的iat字段代表公布工夫,此Token设置为在公布后5秒过期⏰。如果你不想领有永远无效的Token你应该给你的JWT设置一个正当的到期工夫,工夫的长短取决于你的利用,咱们将在这里应用时长为一天Token,并在登录操作中生成它们,对于NodeJS应用程序,代码应该如下所示: const jwt = require('jsonwebtoken');const payload = { "sub": "1234567890", "name": "John Doe", "iat": 1516234022}const token = jwt.sign(payload, 'your-secret', {expiresIn: '1d'})当这个token过期时验证器会返回一个error,而且后端一旦收到须要受权的申请,就会以未受权的响应状态进行响应。通常,你将从客户端删除令牌并将用户重定向到登录页面。因而,在这个例子中,所有用户在应用你的应用程序1天后将主动登记。 很酷,但我还是想登记!如前所述,你不能在Token创立后手动使其过期,你实际上不能像应用session那样在服务器端应用JWT登记或者,除非,你能够...应用JWT应该是无状态的,这意味着你应该将所需的所有存储在payload中,并跳过对每个申请执行DB查问,然而如果你打算有一个严格的登记性能,无奈期待Token主动过期,即便你曾经从客户端革除了Token,而后你可能须要违反无状态规定并执行一些查问。 有一种实现可能是,存储一个所谓的“黑名单”所有Token是无效的,还没有到期你能够筛选一个领有TTL性能的数据库,TTL被用于为Token记录Token过期之前残余的工夫量。Redis 是一个很好的抉择,这将容许在内存中快速访问列表,而后,在某个中间件中,运行在每个受权申请上,你应该查看提供的令牌是否在黑名单中️,如果在的话就抛出一个未认证异样,如果没有让它通过,JWT验证将解决它并确定它是否已过期或依然无效。 论断仿佛,在应用JSON Web令牌时创立洁净的登记流程并不那么简略,你应该让Token放弃活动状态,直到它本人过期为止;或者,如果你心愿在用户登记时限度Token的应用,则抉择贮存一个Token黑名单。总而言之,只需遵循以下4个要点: 设置令牌的正当过期工夫登记时从客户端删除存储的Token领有不再流动Token的数据库,这些Token仍有一些生存工夫针对每个申请依据黑名单查问受权状况

January 3, 2022 · 1 min · jiezi

关于jwt:KubeCube-用户管理与身份认证

前言KubeCube (https://kubecube.io) 是由网易数帆近期开源的一个轻量化的企业级容器平台,为企业提供 kubernetes 资源可视化治理以及对立的多集群多租户治理性能。KubeCube 社区将通过系列技术文章解读 KubeCube 的设计特点和技术实现,帮忙开发者和用户更快地了解和上手 KubeCube。本文是第三篇,重点介绍 KubeCube 中用户治理与身份认证的实现计划。 用户治理 所有 Kubernetes 集群都有两类用户:由 Kubernetes 治理的服务账号和普通用户。Kubernetes 假设普通用户是由一个与集群无关的服务通过以下形式之一进行治理的:* 负责散发私钥的管理员* 相似 Keystone 或者 Google Accounts 这类用户数据库* 蕴含用户名和明码列表的文件有鉴于此,Kubernetes 并不蕴含用来代表普通用户账号的对象。 普通用户的信息无奈通过 API 调用增加到集群中。依据 Kubernetes 官网所述,Kubernetes 自身并不间接提供用户治理的个性,不反对普通用户对象,更不存储普通用户的任何信息。如果须要创立一个用户,须要为该用户创立私钥和证书,通过证书进行身份认证。并且,因为不存储用户信息,集群管理员无奈集中管理用户,对其余用户无感知。因而,KubeCube 首先从新定义了用户这一概念,即提供了 User 这一资源类型,存储用户信息,进行用户治理,同时不便后续的身份认证和权限校验等。 apiVersion: user.kubecube.io/v1kind: Usermetadata: name: 登录账号,用户惟一标识,用户自定义,不可反复,不可批改spec: password: 明码,必填,零碎会将明码进行md5加盐加密后保留 displayName: 用户名 email: 邮箱 phone: 电话 language: 语言:en/ch loginType: 用户登录形式:normal/ldap/github/... state: 用户状态:normal/forbiddenstatus: lastLoginTime: 上次登录工夫 lastLoginIp: 上次登录IP用户能够由管理员在前端页面手动创立,也能够在应用内部认证第一次登录时零碎主动创立。因而,用户在注册形式上能够分为零碎一般注册用户和第三方受权登录用户。但对于这两种创立形式,都是对应在管控集群创立相应的 User cr。而后 Warden 的资源同步管理器会将该 cr 从管控集群同步到计算集群,以便于后续多集群对立认证。 这样,在用户治理页面,只须要查问管控集群内的 User 资源,即可实现用户的集中管理。并且,能够轻松地增加用户、查问用户以及对用户元信息的批改。 身份认证在 KubeCube 中,反对本地认证和内部认证。本地认证是指,在 KubeCube 中创立普通用户,用户再应用其创立时注册的用户名明码进行登录和认证。而内部认证,是指无需创立用户,通过第三方的认证平台认证用户身份,从而拜访 KubeCube。上面将别离介绍这两种认证形式的实现。 ...

December 17, 2021 · 3 min · jiezi

关于jwt:JWT认证与golang实现JWT的demo

JWT=JSON Web Token,是目前较为风行的分布式认证计划。 认证计划个别罕用传统的Cookie/Session认证计划,认证过程: 用户向服务器发送username+password;服务器验证当前,存储该用户的登录信息,如userId/role/loginTime等;服务器向用户返回 session_id,写入用户的cookie;用户随后的每一次申请,都通过Cookie,将session_id传回服务器;服务器收到session_id,找到后期保留的数据,由此失去用户的身份(userId/role等);在分布式系统中,常遇到跨域认证的问题,比方A网站和B网站 是同一家公司的关联服务器。现要求,用户只有在其中一个网站登录,再拜访另一个网站就会主动登录,对该问题,罕用的计划有: 传统的Cookie/Session计划:将session集中长久化并做cache,每来一个申请,都要用申请中的sessionId进行认证;JWT计划:服务端不存储session数据,认证信息存储在客户端,服务端仅要session的颁发和校验;JWT(JSON Web Token)是目前较为风行的跨域认证解决方案。 JWT的认证过程JWT的认证过程是,客户端将用户名和明码传入服务端,服务端通过认证后,将生成一个JSON对象,发回给用户,JSON对象大略的格局: { "姓名": "张三", "角色": "管理员", "到期工夫": "2018年7月1日0点0分"}当前客户端再与服务端通信的时候,都要带上这个JSON对象,服务端校验JSON对象的内容认证用户。 这样服务端不必保留任何session信息,服务端变成无状态的,扩展性较好。 JWT的数据结构: Header:形容JWT的元数据,如签名算法;Payload:寄存理论传递的数据,除了官网定义的签发人、过期工夫等四段,还能够寄存公有字段,如userId/userName等信息;Signature:对前两局部的签名,避免数据篡改; JWT的长处:服务端便于扩大,因为服务端不存储认证信息,无状态的,十分利于扩大。 JWT的毛病:JWT一旦签发,在到期之前始终无效,除非服务端部署额定的逻辑。 golang-jwt的demohttp-server应用github.com/gin-gonic/gin。jwt应用github.com/dgrijalva/jwt-go。 该demo中,client通过POST /login进行登录,而后获取JWT token,而后通过在header中带上token,POST /order进行商品下单。 生成jwt tokenJWT token在用户/login的时候,由服务端调配: type AuthClaim struct { UserId uint64 `json:"userId"` jwt.StandardClaims}var secret = []byte("It is my secret")const TokenExpireDuration = 2 * time.Hour// 生成JWT tokenfunc GenToken(userId uint64) (string, error) { c := AuthClaim{ UserId: userId, StandardClaims: jwt.StandardClaims{ ExpiresAt: time.Now().Add(TokenExpireDuration).Unix(), Issuer: "TEST001", }, } //应用指定的签名办法创立签名对象 token := jwt.NewWithClaims(jwt.SigningMethodHS256, c) // 应用指定的secret签名并取得残缺的编码后的字符串token return token.SignedString(secret)}校验jwt tokenlogin胜利后,用户再申请其它的request时,带上该JWT token,交由服务端的middleware认证,认证OK后,才会失去解决: ...

November 6, 2021 · 1 min · jiezi

关于jwt:JWT登录鉴权避免在用户操作的过程中JWT到期跳转登录

以后我的项目JWT登录鉴权办法及问题以后登陆鉴权办法用户登录时,返回一个JWT,由前端存储在本地。尔后用户每次向须要权限的API发出请求时带上该JWT用于验证身份。后端收到JWT后,验证JWT是否正确且未过期: 如果正确且未过期,则返回资源。如果不正确,则返回不正确的状态码;如果已过期,则返回已过期的状态码,要求从新登录。问题应用JWT实现登录鉴权时,因为JWT有固定的过期工夫,可能在用户正在进行操作的过程中恰好过期,而后忽然跳转到登录界面,造成较差的用户体验。 指标应用JWT实现登录鉴权,当且仅当用户在一段时间内不对系统进行任何操作时才要求用户从新登录,并且尽可能保障JWT的安全性。 解决办法及优缺点剖析解决办法一:只应用一个JWT token(不举荐)具体实现用户登录时,返回一个JWT,由前端存储在本地。尔后用户每次向须要权限的API发出请求时带上该JWT用于验证身份。后端收到JWT后,验证该JWT是否正确: 如果不正确,则间接返回错误代码;如果正确,则验证该JWT是否过期: 如果没有过期,则间接返回资源;如果过期,则计算过期工夫: 如果过期工夫没有超过某阈值,则返回资源和新的JWT;如果过期工夫超过某阈值,则返回错误代码。要求从新登录。长处实现了当且仅当用户在一段时间内不对系统进行任何操作时才要求用户从新登录。当JWT过期时如果用户还在操作系统,会向后端发送刚刚过期的JWT,此时JWT的过期工夫没有超过阈值,间接返回资源和新的JWT,实现用户无感书最新。然而如果当JWT过期之后的一段时间(阈值内)用户都没有操作系统,当用户再次操作系统时,会向后端发送过期工夫超过阈值的JWT,后端会返回错误代码,实现从新登录。 毛病安全性较低。如果频繁发送申请,能够应用一个JWT实现永恒登录。一旦JWT被窃取,攻击者能够应用失去的JWT永恒伪造用户获取信息。 解决方案二:应用两个JWT token(举荐)具体实现用户登录时,返回两个JWT(access token和refresh token),一个用于在申请资源验证身份的access token,一个用于在access token过期时更新access token的refresh token。其中refresh token的有效期较长(如7天),而access token的有效期较短(如1小时)。由前端存储在本地。尔后用户每次向须要权限的API发出请求时带上access token用于验证身份。后端收到access token后:验证该access token是否正确: 如果不正确,则间接返回错误代码;如果正确,则验证该access token是否过期: 如果没过期,则间接返回资源;如果过期,则返回过期的错误代码。前端收到过期错误代码后应用refresh token向更新接口申请新的access token,更新接口判断refresh token是否过期: 如果没有过期,则返回新的access token和新的refresh token,将之前所有由同一refresh token生成的refresh token都置为有效(保护一个有效列表)。前端应用新的access token从新向须要权限的API发出请求,获取资源。如果过期,则返回错误代码,要求从新登录。如果收到已被置为有效的refresh token,则将以后所有与有效refresh token为同一用户的refresh token和access token都置为有效(具体来说是将该用户的拜访置为有效),直到用户从新登录。应用这种办法,既能防止在用户操作的过程中呈现忽然跳转登录(次要解决了两次操作之间的不统一景象,不会呈现一次申请还能失常获取资源,下一次申请资源就忽然跳转到登录页面的景象),又能保障较高的安全性。 解释Q:为什么不应用永恒无效的refresh token?A:为了实现更高的安全性。永恒无效的refresh token一旦被窃取,攻击者能够应用该token永恒假冒用户获取个人信息。而每次应用refresh token就更换一个新的refresh token的话,即便refresh token被窃取,也会在肯定工夫内生效,攻击者应用的工夫无限。 Q:为什么refresh token获取新的access token时须要同时更新refresh token?A:因为如果不更新refresh token的话,就无奈防止用户两次操作之间的不一致性。可能用户在refresh token过期前一分钟还能失常操作,一分钟后就忽然跳转到登录页面,造成不敌对的用户体验。 Q:为什么要在应用refresh token取得新的access token和refresh token后将用于申请新token的refresh token置为有效?A:为了防止之前的refresh token被窃取后导致的重放攻打(应用之前的refresh token申请新的access token和refresh token)。 Q:为什么更新接口在收到已置为有效的refresh token后会将所有应用第一个refresh token失去的refresh token都禁止?A:因为不晓得被窃取的是哪个refresh token。有可能攻击者应用第一个refresh token,并应用该token在更新接口获取了新的refresh token,此时用户可能应用旧的refresh token(已被置为有效)申请更新接口。也有可能攻击者窃取到第一个refresh token后,用户首先应用该token在更新接口获取了新的refresh token,此时攻击者可能应用旧的refresh token(已置为有效)申请更新接口。详见:auth0-refresh-token-rotation ...

October 2, 2021 · 1 min · jiezi

关于jwt:智汀家庭云开发指南Golang用户模块

对智汀家庭云即smart-assistant(以下简称SA)的用户,角色,权限的阐明。 1.用户(1)SA的管理员 当某用户应用智汀App为某个家庭/公司增加SA之后,该用户就是SA的管理员,创建者,领有SA所有的权限,包含邀请其余用户退出该家庭,为成员调配角色等。 (2)smart-assistant-token smart-assistant-token 是家庭成员应用SA性能的用户凭证。每个用户退出一个绑定了SA的家庭时,SA会给该用户下发凭证。一个SA的用户凭证 只容许在该SA下应用。smart-assistant-token只能通过增加SA或者退出其余增加了SA的家庭获取。 smart-assistant-token的生成应用了securecookie.CodecsFromPairs(),securecookie.EncodeMulti()办法。 (3)设置账号密码 智汀App默认应用smart-assistant-token进行用户鉴权。如果您领有智汀专业版,您能够通过设置账号密码后,应用账号密码登录智汀专业版以 体验SA更多的性能。 (4)邀请其他人退出您的家庭/公司 领有生成邀请码权限的用户能够通过生成邀请二维码,供别人扫描以退出您的家庭。生成二维码时须要您抉择相干的角色信息,角色信息示意扫码的用户以什么 角色退出该家庭。每次生成的二维码有效期为十分钟,您能够邀请任何您信赖的人退出您的SA。 每个用户能够屡次扫描二维码退出您的SA,用户在该家庭的角 色以最初一次扫描的二维码为主。二维码的无效信息通过jwt生成,想理解jwt的详细信息能够浏览https://jwt.io/introduction。 (5)将用户踢出您的家庭/公司 您能够应用SA的删除成员性能,将用户踢出您的家庭/公司。留神: SA创建者不容许被删除。 (6)注意事项 每一个角色都领有不同的权限,多个角色间接之间的权限是取并集的。如果您不想您的SA数据受到损失,在生成您的二维码时,审慎抉择角色信息。SA创建者不容许被删除2.角色(1)默认角色 当您增加了SA后,SA会默认创立管理员和成员两个角色,同时将管理员的角色赋予您。不同的角色有不同的权限管制项,用户角色领有的权限越高,能够使 用SA的性能也就越多。 (2)角色的创立、批改、删除 角色的创立、批改、删除只能通过智汀专业版进行操作。角色的创立包含角色名称,角色所领有的权限。角色的批改包含批改角色名称、减少或缩小该角色领有的权限。角色的删除意味着您会删除该角色以及该角色领有的权限,同时领有该角色的用户也会失去该角色。这可能会导致某些用户无奈应用SA的性能。(3)为用户设置角色 SA的创建者和扫码退出SA的用户都领有本人的角色。如果用户有批改成员角色的权限,也能够通过智汀专业版或智汀App设置某一个用户的角色,即减少或删除 这意味着该用户的权限会变高或变低,取决于用户自身领有的角色。 留神: SA创建者的角色不可更改,创建者有且只有一个管理员角色。如果您是SA创建者,请防止您扫描该SA的二维码,这会导致您失去管理员的角色。 (4)多角色 SA容许一个用户领有多个不同的角色。这意味着您在生成邀请二维码或者设置用户角色时能够抉择多个角色。一个SA用户总的权限由该用户的所有角色领有的 权限决定。 (5)注意事项 管理员角色的权限是不可批改的SA创建者的角色不可更改,创建者有且只有一个管理员角色。如果您是SA创建者,请防止您扫描该SA的二维码,这会导致您失去管理员的角色。3.权限(1)阐明 权限是SA用于判断用户是否有对设施、家庭/公司、房间/区域、场景、角色等性能操作的根据。用户具备的权限由其被调配的角色取得。每一个性能都有不同 的权限,但相似批改删除等权限是所有性能都具备的。 与角色相干的权限查看角色列表,容许用户查看该SA领有的角色新增角色,容许用户创立新的角色,并给该角色赋予权限编辑角色,容许用户编辑角色名称和更改角色领有的权限删除角色,容许用户删除角色与场景相干的权限新增场景,容许用户创立场景删除场景,容许用户删除场景批改和删除场景,容许用户删除场景或者批改场景的设置管制场景,容许用户在场景的执行工作中抉择管制场景与房间/区域相干的权限增加房间/区域调整程序批改房间名称查看房间详情删除房间与家庭/公司相干的权限生成邀请二维码,容许用户邀请其他人进入该家庭批改名称批改成员角色,新增或缩小某一成员领有的角色删除成员,只管您领有删除成员的权限,然而您依然不能删除SA创建者这一成员与设施相干的权限增加设施删除设施,SA一旦被增加,任何人都不会领有删除SA的权限。批改设施,批改设施的权限包含批改设施的地位,名称等。管制设施,不同的设施有不同的操作权限。eg:灯有开关,色温,色差灯管制权限,开关只有开关权限。(2)注意事项 场景的批改和管制不仅仅取决于用户是否领有批改和管制场景的权限,还包含该用户是否有对场景中的设施操作项的管制权限。 eg:如果您领有管制场景A的权限,然而您没有场景A外面设施B的开关管制权限,则您同样没有管制该场景A的权限。批改场景也是如此。一旦您在编辑角色页面抉择了批改、删除、管制设施这些权限项,SA会默认将该家庭下的所有设施的所有权限项都赋予这个角色。 eg: 您抉择了删除设施管制项,则该角色领有删除该SA所有设施的权限。咱们建议您通过编辑角色的高级设置选项来抉择您要赋予该角色的设施权限。

September 30, 2021 · 1 min · jiezi

关于jwt:JWT-Token在线编码生成

JWT Token在线编码生成JWT Token在线编码生成 JWT 的三个局部顺次如下Header(头部)Payload(负载)Signature(签名)Header头部{ "alg": "HS256", "typ": "JWT"}Payload(负载)iss (issuer):签发人exp (expiration time):过期工夫sub (subject):主题aud (audience):受众nbf (Not Before):失效工夫iat (Issued At):签发工夫jti (JWT ID):编号Signature(签名)生成规定,secret是秘钥,要严格窃密。HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) https://tooltt.com/jwt-encode/

May 11, 2021 · 1 min · jiezi

关于jwt:在线解析解码jwt-token工具

在线解析解码jwt token工具在线解析解码jwt token工具 JSON Web Token(缩写 JWT)是目前最风行的跨域认证解决方案。本工具提供在线解码的性能 https://tooltt.com/jwt-decode/

May 10, 2021 · 1 min · jiezi

关于jwt:JSON-Web-Tokens-是如何工作的

在用户权限校验的过程中,一个用户如果应用受权信息胜利登录后,一个 JSON Web Token 将会返回给用户端。 因为返回的令牌蕴含有受权信息,应用程序应小心保留这些受权信息,以防止不必要的平安问题。你的应用程序在不须要受权信息的时候,应用程序不应该保留受权胜利后返回的令牌。 应用程序也不应该将这些敏感信息保留在浏览器中,因为这样会更加容易导致信息透露,请参考链接:https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage 中的内容。 在任何时候,如果用户心愿拜访一个受爱护的资源或者路由的时候,用户应该在拜访申请中蕴含 JWT 令牌。通常这个令牌是存储在 HTTP 申请的头部信息,个别会应用 Authorization 字段,应用 Bearer 模式。 Http 头部发送给后盾所蕴含的内容看起来如下所示: Authorization: Bearer <token> 在某些状况下,能够应用无状态的受权机制。服务器上受爱护的路由将会查看随着拜访提交的 JWT 令牌。如果令牌是无效的,用户将会被容许拜访特定的资源。 如果 JWT 令牌中蕴含有必要的信息,服务器的服务端将不须要再次对数据库进行查问以放慢访问速度。当然,不是所有的时候都能够这样进行解决。 当令牌随着头部中的 Authorization 信息一起发送,那么咱们不须要应用 cookies,因而跨域拜访(Cross-Origin Resource Sharing (CORS))也不应该成为一个问题。 上面的示例图展现了JWT 是如何被取得的,同时也展现了 JWT 是如何被应用来拜访服务器 API 的。 应用程序或者客户端,通过对受权服务器的拜访来取得受权。这个可能有不同的受权模式。例如,通常咱们能够应用 OpenID Connect 提供的规范的受权地址来进行受权,请参考链接:http://openid.net/connect/。通常来说一个规范的受权地址为 /oauth/authorize,并且应用上面相似的规范受权流程,请参考链接:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth 中的内容。当受权实现后,受权服务器将会返回拜访令牌(access token)给利用。利用应用取得的令牌来拜访收到爱护的资源(例如 API)等。须要留神的是,通过应用了签名的令牌,只管用户可能没有方法对应用的令牌进行批改,然而令牌中蕴含的所有信息将会裸露给用户或者其余的利用。因而,你不应该在你的令牌中存储密钥或者任何的敏感信息。 https://www.ossez.com/t/json-web-tokens/532

October 2, 2020 · 1 min · jiezi

关于jwt:JSON-Web-Token-的结构是什么

JSON Web Tokens 由应用 (.) 离开的 3 个局部组成的,这 3 个局部别离是: 头部(Header)负载(Payload)签名(Signature)正是因为下面的组织模式,因而一个 JWT 通常看起如上面的表现形式。 xxxxx.yyyyy.zzzzz 让咱们针对下面的模式来具体的剖析下。 头部(Header)在头部的数据中 _通常_ 蕴含有 2 局部的内容:token 的类型,这里应用的是字符 JWT,和应用的的签名加密算法,例如 SHA256 或者 RSA。 例如上面的格局: {"alg": "HS256","typ": "JWT"} 而后,将下面的 JSON 数据格式应用 Base64Url 算法进行哈希,这样你就失去了 JWT 的第一局部。 负载(Payload)JWT 的第二局部为负载,在负载中是由一些 claims 组成的。 Claims 是一些实体(通常指用户)和其余的一一些信息。 有上面 3 种类型的 claims _registered_, _public_ 和 _private_ 。 Registered claims:这些 claims 是事后定义的,这些配置的内容不是必须的然而是举荐应用的,因而提供了一系列约定俗成应用的。比方:iss(issuer), exp(expiration time), sub(subject),aud(audience)和其余的一些更多的配置。 请留神,这些约定俗称的配置只有 3 个字符,以便于压缩数据量。 Public claims:这些数据能够由应用 JWT 的用户自在去定义,然而为了防止抵触,你须要参考在 IANA JSON Web Token Registry 中对它们进行定义,或者将这些内容定义为 URI,并且须要防止可能呈现的抵触。 Private claims:这些内容是自定义的内容,这部分的内容被用于在数据传输短间进行转换的数据。这些数据是没有在 registered 和 public 两头没有定义的内容。 ...

October 2, 2020 · 1 min · jiezi

关于jwt:什么是-JSON-Web-TokenJWT

无关本文档的疾速链接,请参考页面提醒。 链接名称 URL 内容阐明 GitHub MD 源代文件 https://github.com/cwiki-us-docs/cwikius-docs/blob/master/jwt/README.md 将本页面中的内容转换为 MD 文件的手册,并存于 Github 下面 Docsify 转换后的手册 https://cwiki-us-docs.github.io/cwikius-docs/#/jwt/README 将 MD 文件应用 Docsify 转换后的手册链接地址 问题探讨和社区 https://www.ossez.com/tag/jwt 请拜访应用 JWT 标签 CWIKI.US 页面链接 https://www.cwiki.us/display/CWIKIUSDOCS/JWT+-+JSON+Web+Token Confluence 平台的原始翻译文件更新地址 什么是 JSON Web Token(JWT)?JSON Web Token (JWT) 作为一个凋谢的规范 (RFC 7519) 定义了一种简洁自蕴含的办法用于通信单方之间以 JSON 对象的模式平安的传递信息。因为有数字签名,所以这些通信的信息可能被校验和信赖。 JWT 能够应用秘钥(secret)进行签名 (应用 HMAC 算法) 或应用 RSA 或 ECDSA 算法的公钥/私钥对(public/private key)。 只管 JWT 能够在通信的单方之间通过提供秘钥(secret)来进行签名,咱们将会更多关注 已签名(signed)的 token。 通过签名的令牌能够验证其中数据的 _完整性(integrity)_ ,而加密的令牌能够针对其余方 _暗藏(hide)_ 申明。 当令牌(token)应用 公钥/私钥对(public/private key)进行签名的时候,只有持有私钥进行签名的一方是进行签名的。 要害术语的中英文对照token - 令牌secret - 秘钥signature - 签名claims - 要求或者数据

October 1, 2020 · 1 min · jiezi

关于jwt:关于JWT-Token-自动续期的解决方案

前言在前后端拆散的开发模式下,前端用户登录胜利后后端服务会给用户颁发一个jwt token。前端(如vue)在接管到jwt token后会将token存储到LocalStorage中。 后续每次申请都会将此token放在申请头中传递到后端服务,后端服务会有一个过滤器对token进行拦挡校验,校验token是否过期,如果token过期则会让前端跳转到登录页面从新登录。 因为jwt token中个别会蕴含用户的根底信息,为了保障token的安全性,个别会将token的过期工夫设置的比拟短。 然而这样又会导致前端用户须要频繁登录(token过期),甚至有的表单比较复杂,前端用户在填写表单时须要思考较长时间,等真正提交表单时后端校验发现token过期生效了不得不跳转到登录页面。 如果真产生了这种状况前端用户必定是要骂人的,用户体验十分不敌对。本篇内容就是在前端用户无感知的状况下实现token的主动续期,防止频繁登录、表单填写内容失落状况的产生。 实现原理jwt token主动续期的实现原理如下: 登录胜利后将用户生成的 jwt token 作为key、value存储到cache缓存外面 (这时候key、value值一样),将缓存有效期设置为 token无效工夫的2倍。当该用户再次申请时,通过后端的一个 jwt Filter 校验前端token是否是无效token,如果token有效表明是非法申请,间接抛出异样即可;依据规定取出cache token,判断cache token是否存在,此时次要分以下几种状况: cache token 不存在这种状况表明该用户账户闲暇超时,返回用户信息已生效,请从新登录。cache token 存在,则须要应用jwt工具类验证该cache token 是否过期超时,不过期无需解决。过期则示意该用户始终在操作只是token生效了,后端程序会给token对应的key映射的value值从新生成jwt token并笼罩value值,该缓存生命周期从新计算。实现逻辑的外围原理:前端申请Header中设置的token放弃不变,校验有效性以缓存中的token为准。 代码实现(伪码)登录胜利后给用户签发token,并设置token的有效期...SysUser sysUser = userService.getUser(username,password);if(null !== sysUser){ String token = JwtUtil.sign(sysUser.getUsername(), sysUser.getPassword());}...public static String sign(String username, String secret) { //设置token有效期为30分钟 Date date = new Date(System.currentTimeMillis() + 30 * 60 * 1000); //应用HS256生成token,密钥则是用户的明码 Algorithm algorithm = Algorithm.HMAC256(secret); // 附带username信息 return JWT.create().withClaim("username", username).withExpiresAt(date).sign(algorithm);}将token存入redis,并设定过期工夫,将redis的过期工夫设置成token过期工夫的两倍Sting tokenKey = "sys:user:token" + token;redisUtil.set(tokenKey, token);redisUtil.expire(tokenKey, 30 * 60 * 2);过滤器校验token,校验token有效性public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { //从header中获取token String token = httpServletRequest.getHeader("token") if(null == token){ throw new RuntimeException("illegal request,token is necessary!") } //解析token获取用户名 String username = JwtUtil.getUsername(token); //依据用户名获取用户实体,在理论开发中从redis取 User user = userService.findByUser(username); if(null == user){ throw new RuntimeException("illegal request,token is Invalid!") } //校验token是否生效,主动续期 if(!refreshToken(token,username,user.getPassword())){ throw new RuntimeException("illegal request,token is expired!") } ...}实现token的主动续期public boolean refreshToken(String token, String userName, String passWord) { Sting tokenKey = "sys:user:token" + token ; String cacheToken = String.valueOf(redisUtil.get(tokenKey)); if (StringUtils.isNotEmpty(cacheToken)) { // 校验token有效性,留神须要校验的是缓存中的token if (!JwtUtil.verify(cacheToken, userName, passWord)) { String newToken = JwtUtil.sign(userName, passWord); // 设置超时工夫 redisUtil.set(tokenKey, newToken) ; redisUtil.expire(tokenKey, 30 * 60 * 2); } return true; } return false;}...public static boolean verify(String token, String username, String secret) { try { // 依据明码生成JWT效验器 Algorithm algorithm = Algorithm.HMAC256(secret); JWTVerifier verifier = JWT.require(algorithm).withClaim("username", username).build(); // 效验TOKEN DecodedJWT jwt = verifier.verify(token); return true; } catch (Exception exception) { return false; }}本文中jwt的相干操作是基于 com.auth0.java-jwt 实现,大家能够通过浏览原文获取 JWTUtil 工具类。 ...

August 4, 2020 · 2 min · jiezi