asp.net-web-api - 使用JWT在Asp.net Web API上实现身份验证

Question

我一直在阅读有关 JWT 的内容。

但据我了解，它不是一种身份验证机制，而更像是身份验证机制中的关键组件。

我目前已经实现了一个可行的解决方案，但这只是尝试 JWT 并看看它是如何工作的。但我现在追求的是如何利用它。根据我的经验，它基本上只是一种加密机制，为您提供唯一的加密 key 。您还可以将信息放入此 token 中。

我想在 ASP.NET Web API 2 上实现它以供移动应用程序使用。

所以第 1 步:

1. app => 服务器:登录(用户名、密码)
2. 服务器 => 应用程序:登录成功，这是您的 JWT
3. app => 服务器:获取我的个人资料(发送带有请求的 JWT) 然后服务器解密 JWT 并确定请求身份。

现在这只是我的理解，看我可能走在完全错误的道路上。

JWT 的理想状态是让您不必对每个请求进行身份验证吗？我只需对用户凭据进行一次身份验证(在初始登录时)，然后服务器就可以简单地使用 JWT，而无需在数据库中查找用户密码和用户？

我只想使用 JWT 来识别用户是谁。我将在对他们进行身份验证后进行授权。据我所知，人们对新的 MVC 以及身份验证和授权有很大的困惑。

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

如何使用 JWT 安全有效地实现身份验证机制？ 我不想只是吐出一些看起来有效的东西，但对安全影响没有任何想法。我确信存在一个可能设计了适合我的要求的安全机制的来源。

我的要求是:

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

谢谢

Answer 1

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

身份验证和授权

• JWT 与身份验证无关。仅当您在创建 JWT 时进行身份验证时，才会访问您的数据库并哈希密码。这与 JWT 正交，您可以按照您喜欢的任何方式执行此操作。我个人喜欢Membership Reboot ，其中也有一个使用 JWT 的很好的示例。
• 理论上，您可以让用户每年输入一次密码，并使 JWT 全年有效。这很可能不是最好的解决方案，如果 JWT 在任何时候被盗，用户资源都会受到损害。

加密

• token 可以但不必加密。加密您的 token 会增加系统的复杂性以及服务器读取 JWT 所需的计算量。如果您要求无人能够在 token 静止时读取 token ，那么这一点可能很重要。
• token 始终由发行者进行加密签名，以确保其完整性。这意味着它们不能被用户或第三方篡改。

声明

您的 JWT 可以包含您想要的任何信息。用户姓名、出生日期、电子邮件等。您可以通过基于声明的授权来执行此操作。然后，您只需告诉您的提供商使用声明原则中的这些声明创建 JWT。以下代码来自成员(member)资格重新启动示例，它向您展示了这是如何完成的。

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);
}

这使您可以精确控制谁在访问您的资源，而无需访问您的处理器密集型身份验证服务。

实现

实现 token 提供程序的一个非常简单的方法是使用 Microsoft's OAuth Authorization Server在您的 WebAPI 项目中。它为您提供了为 API 创建 OAuth 服务器所需的基本信息。

您还可以查看 Thinktecture 的 Identity Server这将使您更轻松地控制用户。例如，您可以轻松地使用身份服务器实现刷新 token ，其中用户经过一次身份验证，然后在一定时间(可能是一个月)内，他们可以继续从身份服务器获取短暂的 JWT。刷新 token 很好，因为它们可以撤销，而 JWT 则不能。此解决方案的缺点是您需要设置另一台或两台服务器来托管身份服务。

为了解决您的最后一点，即入侵者不应该能够复制最后一个请求来访问资源，您必须至少使用 SSL。这将保护 token 在运输中。

如果您要保护极其敏感的内容，则应将 token 生命周期保持在非常短的时间范围内。如果您保护的是不太敏感的东西，则可以延长使用生命周期。 token 有效的时间越长，如果用户的计算机受到威胁，攻击者冒充经过身份验证的用户的时间窗口就越长。