blocks|key|154564|text|你对JWTs的理解很好。但这里有一些更正和一些建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|154565|身份验证和授权|154566|154567|JWTs与身份验证无关。只有当您在创建JWT时进行身份验证时，才会命中数据库和散列密码。这与JWTs是正交的，你可以用任何你喜欢的方式来做。我个人喜欢JWT，它也有一个使用JWTs.|unordered-list-item|154568|Theoretically，的很好的例子，你可以让用户每年输入一次密码，并让Membership+Reboot全年有效。这很可能不是最好的解决方案，如果JWT在任何时候被窃取，用户的资源都会受到损害。|offset|length|154569|154570|加密|154571|154572|令牌可以加密，但不必加密。加密令牌将增加系统的复杂性和服务器读取JWTs所需的计算量。如果您要求在令牌处于静止状态时没有人能够读取它，那么这一点可能很重要。|154573|令牌始终由颁发者进行加密签名，以确保其完整性。这意味着它们不能被用户或第三方篡改。|154574|154575|索赔|154576|你的JWTs可以包含你想要的任何信息。用户名、生日、电子邮件等。您可以使用基于声明的授权来执行此操作。然后，您只需告诉您的提供者使用这些来自claims原则的声明来创建JWT。下面的代码来自Membership+Reboot示例，它向您展示了如何做到这一点。|154577|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);
}|code-block|syntax|javascript|154578|这使您能够精确地控制谁正在访问您的资源，而不会影响到您的处理器密集型身份验证服务。|154579|实现|154580|实现令牌提供程序的一种非常简单的方法是在WebAPI项目中使用Microsoft's+OAuth+Authorization+Server。它为您提供了为您的应用程序接口创建OAuth服务器所需的基础知识。|154581|你也可以看看Thinktecture的Identity+Server，它可以让你更容易地控制用户。例如，您可以使用identity+Server轻松地实现刷新令牌，其中用户只需进行一次身份验证，然后在一段时间内(可能是一个月)，他们可以继续从Identity+server获取短期的JWTs。刷新令牌是好的，因为它们可以被撤销，而JWT不能。此解决方案的缺点是，您需要设置另一个或两个服务器来托管身份服务。|154582|为了处理你的最后一点，入侵者不应该能够复制最后一个请求来访问资源，你必须至少使用SSL。这将保护传输中的令牌。|style|BOLD|154583|如果您要保护极其敏感的内容，则应将令牌的生存期保持在非常短的时间窗口内。如果你在保护一些不太敏感的东西，你可以让它的生命周期更长。令牌有效的时间越长，如果用户的机器被攻破，攻击者必须假冒经过身份验证的用户的时间窗口就越长。|154584|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/brockallen/BrockAllen.MembershipReboot/blob/master/samples/WebApiResourceOwner/ServerApp/Startup.cs|1|http://blogs.msdn.com/b/webdev/archive/2013/09/20/understanding-security-features-in-spa-template.aspx|2|https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki^0|0|0|0|0|12|H|0|0|0|0|0|0|0|0|0|0|0|0|0|V|12|1|0|J|F|2|0|X|B|0|0^^$0|@$1|2|3|4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1U|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1V|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1W|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|1X|8|@]|9|@$J|1Y|K|1Z|1|20]]|A|$]]|$1|L|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|22|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|P|3|Q|5|G|7|24|8|@]|9|@]|A|$]]|$1|R|3|S|5|G|7|25|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|27|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|28|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|10|7|29|8|@]|9|@]|A|$11|12]]|$1|13|3|14|5|6|7|2A|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|2B|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|2C|8|@]|9|@$J|2D|K|2E|1|2F]]|A|$]]|$1|19|3|1A|5|6|7|2G|8|@]|9|@$J|2H|K|2I|1|2J]]|A|$]]|$1|1B|3|1C|5|6|7|2K|8|@$J|2L|K|2M|1D|1E]]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2O|8|@]|9|@]|A|$]]]|1I|$1J|$5|1K|1L|1M|A|$1N|1O]]|1P|$5|1K|1L|1M|A|$1N|1Q]]|1R|$5|1K|1L|1M|A|$1N|1S]]]]

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

<h2>Authentication and Authorization</h2>

<ul>
<li>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 <a href="https://github.com/brockallen/BrockAllen.MembershipReboot/blob/master/samples/WebApiResourceOwner/ServerApp/Startup.cs" rel="nofollow noreferrer">Membership Reboot</a>, which also has a good example of using JWTs.</li>
<li>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. </li>
</ul>

<h2>Encryption</h2>

<ul>
<li>Tokens can, but don't have to be encrypted. Encrypting your tokens will increase the complexity of your system and amount of computation your server needs to read the JWTs. This might be important if you require that no one is able to read the token when it is at rest. </li>
<li>Tokens are always cryptographically signed by the issuer to ensure their integrity. Meaning they cannot be tampered with by the user or a third party. </li>
</ul>

<h2>Claims</h2>

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.

<pre><code>public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
 var svc = context.OwinContext.Environment.GetUserAccountService&lt;UserAccount&gt;();
 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);
}
</code></pre>

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

<h2>Implementation</h2>

A very easy way to implement a Token provider is to use <a href="http://blogs.msdn.com/b/webdev/archive/2013/09/20/understanding-security-features-in-spa-template.aspx" rel="nofollow noreferrer">Microsoft's OAuth Authorization Server</a> in your WebAPI project. It give you the bare bones of what you need to make a OAuth server for your API. 

You could also look into Thinktecture's <a href="https://github.com/thinktecture/Thinktecture.IdentityServer.v3/wiki" rel="nofollow noreferrer">Identity Server</a> 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. 

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.

blocks|key|2743422|text|我写了一篇关于配置OWIN授权服务器以颁发签名的JSON+Web令牌而不是默认令牌的详细博客文章。因此，资源服务器(受众)可以向授权服务器注册，然后它们可以使用由令牌颁发者方颁发的JWT令牌，而不需要在各方之间统一machineKey值。你可以阅读这篇文章的JSON+Web+Token+in+ASP.NET+Web+API+2+using+Owin|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2743423|entityMap|0|LINK|mutability|MUTABLE|url|http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/^0|3L|1A|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I've written detailed blog post about configuring the OWIN Authorization server to issue signed JSON Web Tokens instead of default token. So the resource servers (Audience) can register with the Authorization server, and then they can use the JWT tokens issued by Token issuer party without the need to unify machineKey values between all parties. You can read the post <a href="http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/" rel="noreferrer">JSON Web Token in ASP.NET Web API 2 using Owin</a>

blocks|key|2743538|text|对于正式的概念。身份验证是验证用户身份的过程，而授权是验证用户有权访问哪些内容的过程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2743539|让我们看看现实生活中的例子|offset|length|style|BOLD|2743540|想象一下，你的邻居让你在他不在的时候给他的宠物喂食。在本例中，您有权访问厨房并打开存储宠物食品的橱柜。然而，你不能进入你邻居的卧室，因为他没有明确允许你这样做。即使你有进入房子的权利(身份验证)，你的邻居只允许你进入某些区域(授权)。|2743541|有关更详细的信息，以及对于喜欢更多的用户，请逐步实现，了解如何在Web+API中实际使用JSON+WEB+Token。这是必须阅读的帖子Secure+WebAPI+Using+JSON+WEB+TOKEN|2743542|更新为使用:+System.IdentityModel.Tokens.Jwt+-Version+5.1.4|2743543|entityMap|0|LINK|mutability|MUTABLE|url|https://decatechlabs.com/secure-webapi-using-jwt^0|0|0|D|0|0|H|9|1W|Y|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$D|11|E|12|F|G]]|9|@$D|13|E|14|1|15]]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

For the formal concept . The Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Let’s see the real life example
Imagine that your neighbor has asked you to feed his pets while he is away. In this example, you have the authorization to access the kitchen and open the cupboard storing the pet food. However, you can’t go into your neighbor’s bedroom as he did not explicitly permit you to do so. Even though you had the right to enter the house (authentication), your neighbor only allowed you access to certain areas (authorization).
For more detailed and for users who like more STEP BY STEP implementation on practical use of JSON Web Token in WEB API. This is must read post <a href="https://decatechlabs.com/secure-webapi-using-jwt" rel="nofollow noreferrer">Secure WebAPI Using JSON WEB TOKEN</a>
Updated to use: System.IdentityModel.Tokens.Jwt -Version 5.1.4

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.

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.

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

So step 1:

<ol>
<li>app => Server : Login (user, pasword)</li>
<li>Server => app : Login OK, heres your JWT</li>
<li>app => server : Get my profile (sends JWT with request)
 Server then decrypts JWT and determines the requests Identity.</li>
</ol>

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

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?

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.

So what my question comes down to.

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.

My requirements are:

<ul>
<li>Must only have to check db for users credentials once off per session? Due to the use of bcrypt using a lot of resources to compare passwords.</li>
<li>Must be able to identify the user from their request. (I.e who they are, userId will be sufficient) and preferably without accessing the DB as well</li>
<li>Should be as low overhead as possible, with regards to resources on the server side processing the request. </li>
<li>If an intruder had to copy a devices previous request, then he should not be able to access the real users data. (obviously)</li>
</ul>

Thanks

Using JWT to implement Authentication on Asp.net web API

身份验证

数据库

服务器

OAuth

JSON

我一直在读有关JWT的文章。但据我所知，它不是一种身份验证机制，而更像是身份验证机制中的一个关键组件。我目前已经实现了一个有效的解决方案，但它只是尝试JWT，看看它是如何工作的。但我现在追求的是一个人应该如何利用它。根据我的经验，它基本上只是一种加密机制，给你一个唯一的加密密钥。您还可以将信息放入此令牌中。我想在移动应...

问利用JWT实现Asp.net网络应用程序接口的身份认证
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问利用JWT实现Asp.net网络应用程序接口的身份认证EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问利用JWT实现Asp.net网络应用程序接口的身份认证
EN