使用JWT在Asp.net Web API上实现身份验证 [英] Using JWT to implement Authentication on Asp.net web API

查看:83
本文介绍了使用JWT在Asp.net Web API上实现身份验证的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我一直在阅读有关JWT的信息.

I have been reading about JWT.

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

But from what I read it is not an authentication mechanism but more like a crucial component in a Authentication mechanism.

我目前已经实现了一个可行的解决方案,但这只是尝试JWT并查看其工作原理.但是我现在所要做的就是应该如何利用它.根据我的经验,它基本上只是一种加密机制,可以为您提供唯一的加密密钥.您还可以在此令牌中放入信息.

I have currently implemented a solution which works, but it was just to try out JWT and see how it works. But what I am after now is how one should make use of it. From my experience of it its basically just an encryption mechanism that gives you a unique encrypted key. You are also able to put information inside of this token.

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

I am wanting to implement it in terms on a ASP.NET web api 2 to be consumed by a mobile application.

第1步:

  1. app =>服务器:登录(用户,密码)
  2. Server => app:登录OK,这是您的JWT
  3. app =>服务器:获取我的个人资料(通过请求发送JWT) 然后,服务器解密JWT并确定请求的身份.
  1. app => Server : Login (user, pasword)
  2. Server => app : Login OK, heres your JWT
  3. app => server : Get my profile (sends JWT with request) Server then decrypts JWT and determines the requests Identity.

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

Now this is just my understanding of it, Look I could be on the totally wrong path.

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

Is the Ideal of JWT so that you dont have to authenticate on every request? I just authenticate the users credentials once (on the initial login) and there on after the server can simply use JWT and no have to lookup the users pw and user in the DB?

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

I just want to use the JWT to Identity who the user is. I will then authorize then after i have authenticated them. As I know there is a big confused with the new MVC and Authentication and Authorization.

所以我的问题归结为

如何使用JWT安全有效地实施身份验证机制? 我不想只是咳嗽一些似乎可行的方法,并且对安全隐患一无所知.我确信在某些地方可能已经设计出了适合我要求的安全机制.

How can I safely and effectively Implement a Authentication Mechanism Using JWT? I don't want to just cough something up that seems to work and not have any Idea of the security implications. I am sure that there exists a source some where that has possibly designed a secure mechanism that would suit my requirements.

我的要求是:

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

谢谢

推荐答案

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

Your understanding of JWTs is good. But here are a couple corrections and some recommendations.

  • JWT与身份验证无关.仅当您在创建JWT时进行身份验证时,才会击中数据库密码和哈希密码.这与JWT正交,您可以按照自己喜欢的任何方式进行操作.我个人喜欢会员重新启动,这也是使用JWT的一个很好的例子.
  • 理论上,您可以让用户每年输入一次密码,并使JWT在整个一年中都有效.如果JWT在任何时候被盗,那么用户资源将受到损害,这极有可能不是最佳解决方案.
  • JWTs have nothing to do with authentication. Hitting your DB and hashing passwords only happens when you authenticate on creation of the JWT. This is orthogonal to JWTs and you can do that in any way you like. I personally like Membership Reboot, which also has a good example of using JWTs.
  • Theoretically, you could have the user enter a password once a year and have the JWT be valid that entire year. This most likely not the best solution, if the JWT gets stolen at any point the users resources would be compromised.
  • 令牌可以但不必加密.对令牌进行加密将增加系统的复杂性,并增加服务器读取JWT所需的计算量.如果您要求在静止时没有人能够读取令牌,这可能很重要.
  • 令牌始终由发行者加密签名以确保其完整性.意味着它们不能被用户或第三方篡改.

您的JWT可以包含您想要的任何信息.用户名,生日,电子邮件等.您可以使用基于声明的授权来执行此操作.然后,您只需告诉您的提供者使用索赔原则"中的这些索赔创建JWT.以下代码来自该Membership Reboot示例,它向您展示了如何完成此操作.

Your JWTs can contain any information you want. The users name, birthdate, email, etc. You do this with claims based authorization. You then just tell your provider to make a JWT with these claims from the Claims Principle. The following code is from that Membership Reboot example and it shows you how this is done.

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

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

This allows you to control with precision whom is accessing your resources, all without hitting your processor intensive authentication service.

实现令牌提供程序的一种非常简单的方法是使用

A very easy way to implement a Token provider is to use Microsoft's OAuth Authorization Server in your WebAPI project. It give you the bare bones of what you need to make a OAuth server for your API.

您还可以查看Thinktecture的身份服务器,它可以为您提供很多帮助更容易控制用户.例如,您可以轻松地使用身份服务器实现刷新令牌,在该服务器中,对用户进行一次身份验证,然后在一定时间(可能一个月)内,他们可以继续从身份服务器获取短暂的JWT.刷新令牌是好的,因为它们可以被吊销,而JWT则不能.该解决方案的缺点是您需要设置另一台或两台服务器来承载身份服务.

You could also look into Thinktecture's Identity Server which would give you much easier control over users. For instance, you can easily implement refresh tokens with identity server where the user is authenticated once and then for a certain amount of time (maybe a month) they can continue getting short lived JWTs from the Identity Server. The refresh tokens are good because they can be revoked, whereas JWTs cannot. The downside of this solution is that you need to set up another server or two to host the Identity service.

要处理您的最后一点,即入侵者不能复制上一个请求以获取对资源的访问权限,您必须至少使用SSL.这将保护令牌在运输中.

To deal with your last point, that an intruder should not be able to copy the last request to get access to a resource, you must use SSL at a bare minimum. This will protect the token in transport.

如果您要保护非常敏感的东西,则应将令牌生存期保持在很短的时间范围内.如果您保护的东西不那么敏感,则可以延长使用寿命.如果令牌有效,则令牌越长,如果攻击者的计算机受到威胁,攻击者将不得不冒充经过身份验证的用户的时间窗口越大.

If you are protecting something extremely sensitive, you should keep the token lifetime to a very short window of time. If you are protecting something less sensitive, you could make the lifetime longer. The longer the token if valid, the larger the window of time a attacker will have to impersonate the authenticated user if the user's machine is compromised.

这篇关于使用JWT在Asp.net Web API上实现身份验证的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆