标签: jwt

我想知道在更改密码/注销时不使用db而使JWT无效的最佳实践.

我有以下想法通过点击用户数据库处理上述2个案例.

1.密码更改,我检查存储在用户db中的密码(散列).

2.注销时,我在用户数据库中保存了最后注销时间,因此通过比较令牌创建时间和注销时间,我可以使这种情况无效.

但是这两种情况是以每次用户点击api时命中用户数据库为代价的.任何最佳实践表示赞赏.

更新: 我不认为我们能够在没有命中数据库的情况下使JWT无效.所以我想出了一个解决方案.我已经发布了我的答案,如果您有任何疑虑,欢迎您.

我在我的Web API应用程序中创建了基于JWT的身份验证.我无法弄清楚它们之间的区别

1. 基本令牌
2. 持票人令牌

有人可以帮帮我吗？

我正在尝试制作一个服务器应用程序来定期从我自己的GA帐户中提取Google Analytics数据.请注意,它是一个访问我自己的数据的个人服务器端应用程序,即没有最终用户访问此应用程序.

因此,我在Google API控制台中将我的应用程序注册为服务应用程序,该应用程序为我提供了客户端ID和私钥.据我所知,服务应用程序不使用应用程序密钥和重定向URL,因为此服务器到服务器身份验证流程中没有最终用户.实际上,Google API控制台没有给我任何机密,也没有提示我提供重定向网址.

不幸的是,我无法弄清楚如何在Google的PHP客户端API中验证我的服务应用程序.有关于验证的Web应用程序广泛的文件与最终用户.

Google的文档表明,可以通过使用私钥对JWT请求进行签名来验证服务器到服务器.我只是无法弄清楚如何在PHP客户端API中做(虽然我浏览了源代码,但肯定有一个脚本用私钥签署请求.)

我在这里错过了什么吗？如何使用我的私钥和Google PHP客户端API对服务应用程序执行身份验证？

编辑清晰

我正在构建一个由Angular2单页面应用程序和在ECS上运行的REST API组成的系统.API在.Net/Nancy上运行,但这可能会发生变化.

我想尝试一下Cognito,这就是我想象的身份验证工作流程:

1. SPA登录用户并收到JWT
2. SPA会在每次请求时将JWT发送到REST API
3. REST API验证JWT是否可信

我的问题是关于第3步.我的服务器(或者更确切地说:我的无状态,自动扩展,负载平衡的Docker容器)如何验证令牌是否可信？由于"服务器"还没有出台的智威汤逊本身,它不能使用自己的秘密(如在基本JWT例如描述这里).

我已经阅读了Cognito文档并搜索过很多内容,但是我找不到任何关于如何在服务器端使用JWT的好指南.

我一直在读JWT.

但从我读到的内容来看,它不是一种身份验证机制,而更像是身份验证机制中的一个关键组件.

我目前已经实现了一个有效的解决方案,但它只是试用JWT并看看它是如何工作的.但我现在所追求的是如何利用它.根据我的经验,它基本上只是一种加密机制,可以为您提供唯一的加密密钥.您还可以将信息放在此令牌内.

我希望在ASP.NET web api 2上实现它以供移动应用程序使用.

所以第1步:

1. app =>服务器:登录(用户,密码)
2. Server => app:登录OK,继承你的JWT
3. app => server:获取我的个人资料(发送带请求的JWT)服务器然后解密JWT并确定请求身份.

现在这只是我对它的理解,看起来我可能走在完全错误的道路上.

是JWT的理想选择,以便您不必在每次请求时进行身份验证吗？我只是验证用户凭证一次(在初始登录时),然后服务器可以简单地使用JWT,而不必在数据库中查找用户pw和用户？

我只想使用JWT来识别用户身份.然后,在我对它们进行身份验证后,我将授权.据我所知,新的MVC和身份验证和授权存在很大的混淆.

那么我的问题归结为什么.

如何使用JWT安全有效地实施身份验证机制？我不想只是咳嗽似乎有用的东西而且没有任何关于安全隐患的想法.我确信存在一些可能设计出符合我要求的安全机制的源.

我的要求是:

• 每次会话只需要一次性检查db for users凭据吗？由于使用bcrypt使用大量资源来比较密码.
• 必须能够从他们的请求中识别用户.(即他们是谁,userId就足够了),最好也不用访问数据库
• 对于处理请求的服务器端的资源,应尽可能降低开销.
• 如果入侵者必须复制设备先前的请求,那么他应该无法访问真实用户数据.(明显)

谢谢

我认为OAuth基本上是基于令牌的身份验证规范,但大多数时候框架的行为就像它们之间存在差异一样.例如,如下图所示,Jhipster会询问是使用基于OAuth还是基于令牌的身份验证.

这些不一样吗？究竟有什么区别,因为它们的实现中都包含令牌？

JWT规范提到了jti声称,据称可以用作防止重放攻击的随机数:

jti(JWT ID)声明为JWT提供唯一标识符.标识符值必须以确保将相同值偶然分配给不同数据对象的概率可忽略的方式分配; 如果应用程序使用多个发行者,则必须在不同发行者生成的值之间防止冲突.jti声明可用于防止重放JWT.jti值是区分大小写的字符串.使用此声明是可选的.

我的问题是如何实现这一目标？我是否需要存储以前使用过的jtis并在每次请求时发出新的JWT？如果是这样,这不会破坏JWT的目的吗？为什么使用JWT而不是仅仅在数据库中存储随机生成的会话ID？

我的REST API有一个mongo数据库,我并不反对添加一个redis实例.是否有比JWT更好的身份验证选项？我主要只是不想在客户端上存储密码,这会消除HTTP身份验证作为选项,但是,随着我对这个JWT内容的深入了解,我开始感觉好像自定义令牌实现或不同标准可能更好适合我的需要.是否存在基于令牌的身份验证的任何节点/快速包,它们支持令牌撤销和旋转令牌？

非常感谢任何建议.

将jwt(json web令牌)作为GET请求的查询参数放入url是否安全？

使用数据库会话令牌系统,我可以使用用户名/密码进行用户登录,服务器可以生成令牌(例如uuid)并将其存储在数据库中并将该令牌返回给客户端.来自其上的每个请求都将包括令牌,并且服务器将查询令牌是否有效以及它属于哪个用户.

使用JWT,由于保留在服务器上的密钥和客户端保留并随每个请求发送的签名令牌的组合,因此无需为会话/令牌保存任何数据库.

这很好,但除了保存数据库检查每个请求(因为它只是检查哈希表,这将是快速的),我不清楚使用JWT的优点是什么.你能熟悉这个解释吗？让我们忽略cookie,它特别是如上所述的数据库自定义令牌和JWT,我试图比较和理解它的好处.

使用System.IdentityModel.Tokens时出现冲突:

using System;
using System.Configuration;
using System.Data;
using System.Data.SqlClient;
using System.IdentityModel.Tokens;
using System.IdentityModel.Tokens.Jwt;
using System.Text;

public voidGenereToken()
{
    const string sec = "401b09eab3c013d4ca54922bb802bec8fd5318192b0a75f201d8b3727429090fb337591abd3e44453b954555b7a0812e1081c39b740293f765eae731f5a65ed1";
    var now = DateTime.UtcNow;
    var securityKey = new InMemorySymmetricSecurityKey(Encoding.Default.GetBytes(sec));
    var signingCredentials = new SigningCredentials(securityKey,
            SecurityAlgorithms.RsaSha256Signature, SecurityAlgorithms.Sha256Digest);

    var header = new JwtHeader(signingCredentials);

    var payload = new JwtPayload
    {
        {"iss", "a5fgde64-e84d-485a-be51-56e293d09a69"},
        {"scope", "https://example.com/ws"},
        {"aud", "https://example.com/oauth2/v1"},
        {"iat", now},
    };

    var secToken = new JwtSecurityToken(header, payload);

    var handler = new JwtSecurityTokenHandler();
    var tokenString = handler.WriteToken(secToken);
    Console.writeLine(tokenString)
}

我创建标题时出现以下错误(var header = …