我想知道在更改密码/注销时不使用db而使JWT无效的最佳实践.
我有以下想法通过点击用户数据库处理上述2个案例.
1.密码更改,我检查存储在用户db中的密码(散列).
2.注销时,我在用户数据库中保存了最后注销时间,因此通过比较令牌创建时间和注销时间,我可以使这种情况无效.
但是这两种情况是以每次用户点击api时命中用户数据库为代价的.任何最佳实践表示赞赏.
更新: 我不认为我们能够在没有命中数据库的情况下使JWT无效.所以我想出了一个解决方案.我已经发布了我的答案,如果您有任何疑虑,欢迎您.
在现代网络浏览器中,假设我做了setTimeout10分钟(在12:00),5分钟后让计算机进入睡眠状态,当系统再次唤醒时会发生什么?如果它在10分钟之前(12:09)或之后(16:00)醒来会发生什么?
我问的原因是因为我想每10分钟要求一个新的身份验证令牌,我不确定浏览器是否会做正确的事情并且如果长时间醒来后立即请求新的令牌时间.
澄清:我不想使用cookies - 我正在尝试在这里建立一个Web服务; 是的,服务器将拒绝旧的和无效的令牌.
使用数据库会话令牌系统,我可以使用用户名/密码进行用户登录,服务器可以生成令牌(例如uuid)并将其存储在数据库中并将该令牌返回给客户端.来自其上的每个请求都将包括令牌,并且服务器将查询令牌是否有效以及它属于哪个用户.
使用JWT,由于保留在服务器上的密钥和客户端保留并随每个请求发送的签名令牌的组合,因此无需为会话/令牌保存任何数据库.
这很好,但除了保存数据库检查每个请求(因为它只是检查哈希表,这将是快速的),我不清楚使用JWT的优点是什么.你能熟悉这个解释吗?让我们忽略cookie,它特别是如上所述的数据库自定义令牌和JWT,我试图比较和理解它的好处.
I am referencing another SO post that discusses using refresh tokens with JWT.
JWT (JSON Web Token) automatic prolongation of expiration
I have an application with a very common architecture where my clients (web and mobile) talk to a REST API which then talks to a service layer and data layer.
I understand JWT token authentication, but I am a little confused at how I should use refresh tokens.
I want my JWT authentication to have the following properties:
JWT …
在Auth0中,您可以使用刷新令牌.在此链接中,我们可以看到许多返回的参数:
lock.showSignin({
authParams: {
scope: 'openid offline_access'
}
}, function (err, profile, id_token, access_token, state, refresh_token) {
// store refresh_token
});
Run Code Online (Sandbox Code Playgroud)
显然,access_tokens可用于检索用户配置文件数据.但这似乎是oauth特有的,我认为auth0使用openid?
id_token和之间有什么区别access_token?
在安全性,身份验证策略方面,我是一个完整的菜鸟.所以我正在阅读这篇关于"基于令牌的身份验证"的文章:https: //scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
我有两个问题:
我不明白为什么中间人(或黑客)无法看到客户端发送的令牌并使用相同的方式冒充客户/人来检索资源?是什么让JSON Web Tokens/OAuth2基于身份验证在这个意义上更安全?如果我们每次都使用一次性使用的令牌,我会理解即使黑客能够读取令牌,他也无法将其用于其他请求.但是,由于令牌在到期之前保持不变,这是一种更安全的身份验证策略?
服务器如何知道客户端发送的令牌是有效的,即服务器在登录期间与客户端交换的内容.服务器是否存储在数据库或某处生成的令牌并继续更新"上次访问的时间戳"或其他内容并继续删除last_accessed_time> 1小时前的令牌,以便在1小时不活动后继续使用它?
我有一个由Angular提供的Web API项目,我希望使用JWT令牌来保护它.我已经进行了用户/通过验证,所以我认为我只需要实现JWT部分.
我相信我已经确定了JwtAuthForWebAPI所以使用它的一个例子会很棒.
我假设任何未使用[Authorize]修饰的方法都会像往常一样运行,并且如果客户端传递的令牌不匹配,则[Authorize]修饰的任何方法都将为401.
我还不知道如何在初始身份验证时将令牌发送回客户端.
我正在尝试使用魔术字符串开始,所以我有这个代码:
RegisterRoutes(GlobalConfiguration.Configuration.Routes);
var builder = new SecurityTokenBuilder();
var jwtHandler = new JwtAuthenticationMessageHandler
{
AllowedAudience = "http://xxxx.com",
Issuer = "corp",
SigningToken = builder.CreateFromKey(Convert.ToBase64String(new byte[]{4,2,2,6}))
};
GlobalConfiguration.Configuration.MessageHandlers.Add(jwtHandler);
Run Code Online (Sandbox Code Playgroud)
但我不确定最初是如何回到客户端的.我想我理解如何在客户端上处理这个问题,但是如果你还可以展示这种交互的Angular方面,那么也可以获得奖励积分.
我正在使用Identity Server 3对我的角客户端进行身份验证并生成访问/刷新令牌.
我目前正在为我的Angular客户端设置刷新令牌在48小时后到期.
使用我的Angular应用程序的一些用户需要连续100天签名,而不必重新输入他们的凭据,是否可以仅为特定用户而不是整个客户端设置刷新令牌的到期时间?
我的数据库中有100个用户,我只希望一个特定用户在100天内不需要重新进行身份验证,而其他用户应该每48小时进行一次身份验证.
有点像:
if (user == "Super Man") {
AbsoluteRefreshTokenLifetime = TimeSpan.FromDays(100.0).Seconds,
}
Run Code Online (Sandbox Code Playgroud)
这有可能实现吗?或者我是否仅限于为整个客户端设置刷新令牌过期?
谢谢
我的Web应用程序由许多服务器端的Ajax调用组成RESTful APIs.每次客户登录我的站点时,登录页面JWT将从服务器获得(JSON Web令牌)令牌并将其存储为cookie客户端.(我选择将其存储为cookie,因为这是让浏览器自动发送它的唯一方法,据说它比HTML5 Web存储更安全).令牌中有一个字段描述令牌的到期日期.对于每个Ajax调用,将发送令牌以进行身份验证.
如果客户端长时间停留在我的页面上,则令牌可能会过期.当客户端发出下一个HTTP请求(而不仅仅是REST调用)时,服务器将检测到它.我使用a servlet filter来拦截allHTTP请求并检查令牌是否过期.如果令牌过期,将发送重定向到登录页面的响应.
但是上面的方法存在一个问题:"如何在客户端优雅地处理重定向到登录页面的响应?"
对于non-Ajax发起的HTTP请求,我可以依靠浏览器来处理重定向到登录页面的响应并自动跳转页面.
对于Ajax发起的HTTP请求,似乎我需要向eachajax调用添加额外的逻辑completion handler来检测重定向到登录页面的响应imperatively并使页面跳转.
还是我完全错了?
一些参考:
添加1:
浏览器似乎会透明地处理302重定向.所以也许我可以只返回302重定向到登录页面,无论是ajax调用还是普通页面访问.我会尽力回复.
从这里:
如果响应是HTTP重定向(状态代码301,302,303或307),则必须透明地遵循(除非它违反安全性或无限循环预防措施).任何其他错误(包括401)必须使对象使用该错误页面作为响应.
我尝试使用jjwt库在Java中创建Json Web Token
但是当我尝试延长到期时间时,我遇到了问题.
我通过下面的代码尝试.
public class Main {
public static void main(String args[]) {
byte[] key = new byte[64];
new SecureRandom().nextBytes(key);
Date date = new Date();
long t = date.getTime();
Date expirationTime = new Date(t + 5000l); // set 5 seconds
String compact = Jwts.builder().setSubject("Joe").setExpiration(expirationTime).signWith(SignatureAlgorithm.HS256, key).compact();
System.out.println("compact : " + compact);
try {
String unpack = Jwts.parser().setSigningKey(key).parseClaimsJws(compact).getBody().getSubject();
System.out.println("unpackage 0 : " + unpack);
// check if the expiration work.
Thread.sleep(3000);
System.out.println("unpackage 1 : " + Jwts.parser().setSigningKey(key).parseClaimsJws(compact).getBody().getSubject());
//extend …Run Code Online (Sandbox Code Playgroud) jwt ×9
javascript ×3
oauth-2.0 ×3
token ×3
access-token ×2
c# ×2
.net ×1
ajax ×1
auth-token ×1
auth0 ×1
express-jwt ×1
java ×1
login ×1
node.js ×1
oauth ×1
openid ×1
rest ×1
security ×1
settimeout ×1