如何使用JWT在ASP.NETWebAPI上实现身份验证?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (17)

我一直在阅读关于智威汤逊的内容。

但是从我读到的内容来看,它不是一种认证机制,而更像是认证机制中的关键组件。

我目前已经实施了一个可行的解决方案,但只是试用JWT,看看它是如何工作的。但是现在我所掌握的是如何利用它。从我的经验来看,它基本上只是一个加密机制,它提供了一个独特的加密密钥。也可以将信息放入此令牌中。

我想要在ASP.NET web api 2上实现它,以便被移动应用程序使用。

所以第一步:

  1. app =>服务器:登录(用户,密码)
  2. 服务器=>应用程序:登录确定,继承你的JWT
  3. app => server:获取我的配置文件(向请求发送JWT)服务器然后解密JWT并确定请求标识。

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

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

我只想使用JWT来识别用户是谁。然后我会在授权后再授权他们。据我所知,与新的MVC和身份验证和授权有很大的混淆。

所以我的问题归结为什么。

我如何安全有效地使用JWT实现身份验证机制?我不想只是咳嗽起来,似乎工作,并没有任何安全影响的想法。我相信在某些地方可能会设计出一个适合我需求的安全机制。

我的要求是:

  • 每次会话只需要关闭一次数据库用户凭据?由于使用bcrypt使用大量资源来比较密码。
  • 必须能够从他们的请求中识别用户。(即他们是谁,用户ID就足够了),最好不用访问数据库
  • 关于服务器端处理请求的资源,应尽可能降低开销。
  • 如果入侵者不得不复制设备先前的请求,那么他不应该能够访问真实的用户数据。(明显)
提问于
用户回答回答于

你对JWT的理解是很好的。但这里有一些更正和一些建议。

认证和授权

  • JWT与认证无关。只有在创建JWT时进行身份验证时,才会触发数据库和哈希密码。这与JWT正交,你可以用你喜欢的任何方式做到这一点。我个人喜欢Membership Reboot,这也是使用JWT的一个很好的例子。
  • 理论上,可以让用户每年输入一次密码,并让JWT在整年内有效。这最有可能不是最好的解决方案,如果JWT在任何时候被窃取,用户资源都会受到影响。

加密

  • 令牌可以,但不必加密。加密令牌会增加系统的复杂性和服务器读取JWT所需的计算量。如果您要求在静止时没有人能够读取令牌,这可能很重要。
  • 令牌总是由发行者进行密码签名以确保其完整性。这意味着它们不能被用户或第三方篡改。

声明

JWT可以包含任何您想要的信息。用户名,出生日期,电子邮件等。可以通过基于权利的授权来执行此操作。然后,只需告诉提供商使用索赔原则中的这些索赔来制作JWT。以下代码来自该成员资格重新启动示例,并展示了如何完成此操作。

    public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
    {
        var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
        UserAccount user;
        if (svc.Authenticate("users", context.UserName, context.Password, out user))
        {
            var claims = user.GetAllClaims();


            var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
            context.Validated(id);
        }

        return base.GrantResourceOwnerCredentials(context);
    }

这可以精确地控制访问资源的人员,而无需触击处理器密集型身份验证服务。

履行

实现令牌提供程序的一种非常简单的方法是在您的WebAPI项目中使用Microsoft的OAuth授权服务器。它提供了为API制作OAuth服务器所需的一切。

你也可以看看Thinktecture的Identity Server,这会让你更容易控制用户。例如,可以轻松实现带身份服务器的刷新令牌,用户在该身份服务器上进行一次身份验证,然后在一段时间(可能是一个月)后,他们可以继续从Identity Server获取短期JWT。刷新令牌很好,因为它们可以被撤销,而JWT则不能。此解决方案的缺点是需要设置另外一两台服务器来承载身份服务。

为了解决最后一点,入侵者不应该能够复制上次访问资源的请求,必须至少使用SSL。这将保护运输中的令牌。

如果你保护的东西极其敏感,你应该保持令牌的使用寿命到非常短的时间。如果你保护的东西不太敏感,你可以延长寿命。令牌的有效时间越长,攻击者在用户的计算机遭到入侵时将不得不模拟经过身份验证的用户的时间窗口。

用户回答回答于

我已经撰写了关于配置OWIN授权服务器发布签名JSON Web令牌而不是默认令牌的详细博客文章。因此,资源服务器(Audience)可以向授权服务器注册,然后他们可以使用由令牌发行方发行的JWT令牌,而无需统一各方之间的machineKey值。可以使用Owin阅读ASP.NET Web API 2中的JSON Web Token

扫码关注云+社区