使用JWT在Asp.net Web API上实现身份validation
我一直在阅读关于智威汤逊。
但是从我所读的内容来看，这不是一种authentication机制，而更像是authentication机制中的一个关键组件。
我目前已经实现了一个可行的解决scheme，但只是试用智威汤逊，看看它是如何工作的。 但是现在我所知道的是如何利用它。 从我的经验来看，它基本上只是一个encryption机制，给你一个独特的encryption密钥。 你也可以把信息放在这个令牌里面。
我想要在ASP.NET web api 2上实现它，以供移动应用程序使用。
所以第一步：
- 服务器：login（用户，密码）
- 服务器=>应用程序：login好的，inheritance你的JWT
- app => server：获取我的configuration文件（向请求发送JWT）服务器然后解密JWT并确定请求标识。
现在，这只是我的理解，看我可能是完全错误的道路上。
智威汤逊的理想，所以你不必每个请求进行身份validation？ 我只validation一次用户凭证（在初始login时），然后服务器可以简单地使用JWT，而不必在数据库中查找用户pw和用户。
我只是想使用JWT来识别用户是谁。 然后，我会authentication他们后，然后授权。 据我所知，与新的MVC和身份validation和授权有很大的混淆。
所以我的问题归结为。
我如何安全有效地使用JWT实现身份validation机制？ 我不想只是咳嗽起来，似乎工作，并没有任何安全隐含的想法。 我确信有一些资源可能devise了一个适合我的要求的安全机制。
我的要求是：
- 每次会话一次只能检查数据库的用户凭据一次？ 由于使用bcrypt使用了大量的资源来比较密码。
- 必须能够从他们的请求中识别用户。 （即他们是谁，userId就足够了），最好不要访问数据库
- 应尽可能降低开销，关于服务器端处理请求的资源。
- 如果入侵者不得不复制设备先前的请求，那么他不应该能够访问真实的用户数据。 （明显）
谢谢
你对JWT的理解是好的。 但这里有一些更正和一些build议。
身份validation和授权
- 智威汤逊与authentication无关。 只有在创buildJWT时进行身份validation时，才会触发您的数据库和哈希密码。 这与智威汤逊是正交的，你可以用你喜欢的任何方式做到这一点。 我个人喜欢Membership Reboot ，这也是使用JWT的一个很好的例子。
- 理论上，您可以让用户每年input一次密码，并使JWT全年有效。 这很可能不是最好的解决scheme，如果JWT在任何时候被窃取，用户资源将会受到影响。
encryption
- 令牌可以，但不必encryption。 encryption令牌会增加系统的复杂性和服务器读取JWT所需的计算量。 这可能是重要的，如果你要求没有人能够读取令牌时，它是静止的。
- 令牌总是由发行者encryption签字以确保其完整性。 这意味着他们不能被用户或第三方篡改。
声明
您的JWT可以包含您想要的任何信息。 用户名，出生date，电子邮件等。您可以使用基于声明的授权来执行此操作。 然后，您只需告诉您的提供商使用索赔原则中的这些索赔来制作智威汤逊。 以下代码来自成员资格重新启动示例，并向您显示如何完成此操作。
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); } 这使您可以精确地控制访问您资源的人员，而不会触及您的处理器密集型身份validation服务。
履行
实现令牌提供程序的一个非常简单的方法是在您的WebAPI项目中使用Microsoft的OAuth授权服务器 。 它为您提供了为您的API创buildOAuth服务器所需的一切。
你也可以看看Thinktecture的Identity Server ，这会让你更容易控制用户。 例如，您可以轻松实现带身份服务器的刷新令牌（用户通过身份validation一次），然后持续一段时间（可能一个月），他们可以继续从身份服务器获取短期JWT。 刷新令牌很好，因为它们可以被撤销，而JWT则不能。 此解决scheme的缺点是您需要设置另外一两个服务器来承载身份服务。
为了处理你的最后一点，入侵者不应该复制最后一个请求来访问资源， 你必须至less使用SSL。 这将保护运输中的令牌。
如果你正在保护一些非常敏感的东西，那么你应该保证令牌的使用寿命到很短的时间。 如果你保护的东西不那么敏感，你可以延长寿命。 令牌的有效时间越长，攻击者在用户机器受到危害时将冒充authentication用户的时间窗口越大。
我已经写了关于configurationOWIN授权服务器发布签名的JSON Web Tokens而不是默认令牌的详细博客文章。 因此，资源服务器（Audience）可以在授权服务器上注册，然后他们可以使用由令牌发行方发行的JWT令牌，而不需要统一各方之间的machineKey值。 您可以使用Owin阅读ASP.NET Web API 2中的JSON Web Token
