如何在基于令牌的机制中验证访问令牌以访问受保护的资源? [英] How access token is validated for accessing protected resources in token based mechanism?

问题描述

我想做一个基于令牌的机制，使我可以拥有支持多个客户端的SPA或移动应用程序.

我的Web服务引擎和应用程序的用例:

我的网络应用程序:客户端将注册其应用程序(SPA或移动应用程序).他们将在注册时获得客户端ID.只有SPA或移动设备的客户端ID作为密钥才会被泄露.应用程序，因此我只是提供clientid.

Web服务引擎:登录到客户端的相应应用程序后，通过管理每个用户的会话来支持多个客户端.

因此，假设有2位客户端已将其应用程序注册到我的Web应用程序中:

客户端1:MyApp1

客户端2:MyApp2

现在，如果MyApp1有2个具有John和Stephen的用户，并且如果他们登录MyApp1，那么我想使用基于令牌的机制为那些用户管理会话.现在，如果John和Stephen想要访问受保护的资源，那么他们只能通过有效的访问令牌进行访问.

MyApp2也一样.

对于基于令牌的机制，我看到很多问题仅涉及以下文章:

解决方案

您可以控制令牌中包含哪些信息.查看文章中的SimpleAuthorizationServerProvider类:

var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim("sub", context.UserName));
identity.AddClaim(new Claim("role", "user"));

使用声明存储与用户，用户名或角色有关的任何所需信息，这就是您所引用的文章中所发生的情况. 生成的令牌已经包含有关用户的信息.

这摘自文章:

第二种方法"GrantResourceOwnerCredentials"负责 验证发送到授权服务器的用户名和密码 令牌终结点，因此我们将使用创建的"AuthRepository"类 并调用方法"FindUser"检查用户名和 密码有效.

如果凭据有效，我们将创建"ClaimsIdentity"类，然后 将身份验证类型传递给它，在我们的例子中是"bearer token"，然后 我们将添加两个声明("sub"，"role")，这些声明将包含在 签名的令牌.您可以在此处添加其他声明，但令牌大小 肯定会增加.

这就是为什么您不需要将令牌存储在任何地方，令牌是自包含的并且所有内容都以加密形式存储在其中的原因.不要忘记，在添加包含用户名的声明之前，您已经验证了用户名和密码，因此可以保证为有效的用户/密码组合正确创建令牌.当然，您不想将密码存储在令牌中，令牌的全部目的是避免这样做.始终将密码传递给API确实会增加密码被盗的风险，为此，令牌要好得多.

最后，令牌会在您控制的时间后过期，通常是短暂的，因此即使有人确实获得了令牌，它们也不会持续很长时间.

如果您照顾如何传递令牌(即通过https调用的授权标头")，那么您将受到尽可能多的保护，标头将被加密.这里的重点是永远不要通过基本的http发出这样的调用.

您所引用的文章的作者在这个特定领域中是受人尊敬的权威，并且当前是Microsoft MVP，您基本上处于良好状态.继续阅读他的文章，但要注意细节.

-----------有关JWT格式的说明--------------

是，JWT令牌还将包含与其发布日期和到期日期相关的信息.我对此有自己的文章: https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/

查看创建令牌的调用，并查看屏幕快照中返回的信息.

在我的示例中，令牌包含实际的加密令牌，令牌类型，令牌到期的秒数，作为ClientID的受众，令牌的发行时间和到期时间.

这只是令牌的一个示例，您的令牌看上去可能会有所不同，但是您希望我有所想法.使用邮递员查看令牌中返回的内容

关于OAuth2，有许多概念需要理解，它确实需要一些研究和实践.

简而言之，您使用基本授权标头请求令牌，将令牌取回，并告诉您它是什么类型，在我的情况下是承载，这是对受保护资源的任何调用的下一个授权标头. /p>

我的建议是每次开始一个小步骤，使用Postman建立您的电话并了解发生了什么.一旦掌握了这些知识，就可以轻松进行更多的开发.我花了大约6周的时间来整理所有概念，并在第一时间得到解决，但是现在最多只需要几个小时.祝你好运

I want to do token based mechanism where I would be having either SPA or mobile apps supporting multiple clients.

Use case of my web service engine and my application:

My web application: Client will do registration of their application either SPA or mobile apps.They will get client id on registration.Only client id as secret key would be compromised in case of SPA or mobile apps hence I am just providing clientid.

Web service engine: Support multiple client with managing session of each user after login in to respective application of clients.

So let's say there are 2 client who have register their application in to my web application :

Client 1 : MyApp1

Client 2 : MyApp2

Now if MyApp1 have 2 users with John and Stephen and if they login in MyApp1 then i want to manage session for those users with token based mechanism. Now if John and Stephen wants to access protected resource then they can access only through valid accesstoken.

Same goes for MyApp2.

For token based mechanism I have seen lots of question referring to this below article only:

http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/

But the only confusion part in above tutorial and in most of the tutorial is after validating user name and password and generating access token. Does above tutorial is storing access token in server side cookie for validating accesstoken when request comes to access protected resource?

I am really confused here. I know accesstoken validation happens inside [Authorize attribute] but I am not getting without storing accesstoken how above tutorial is validating accesstoken.

My thought is like may be when request comes for accessing protected resources access token is encrypted or decrypted based on machine key attribute in webconfig and this is how access token is validated inside [Authorize] attribute but I am just not sure about this.

解决方案

You can control what information goes inside a token. Look at the SimpleAuthorizationServerProvider class in the article:

var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim("sub", context.UserName));
identity.AddClaim(new Claim("role", "user"));

Use the Claims to store anything you need regarding to the user, their username or roles and this is what happens in the article you referred to. The token generated already contains that information about the user.

This is taken from the article :

The second method "GrantResourceOwnerCredentials" is responsible to validate the username and password sent to the authorization server’s token endpoint, so we’ll use the "AuthRepository" class we created earlier and call the method "FindUser" to check if the username and password are valid.

If the credentials are valid we’ll create "ClaimsIdentity" class and pass the authentication type to it, in our case "bearer token", then we’ll add two claims ("sub","role") and those will be included in the signed token. You can add different claims here but the token size will increase for sure.

This is why you do not need to store the token anywhere,the token is self contained and everything is stored inside it in an encrypted form. Don't forget that before you add a claim containing the username you have already validated the username and password, so you can guarantee that the token is created correctly for a valid user / password combination. Of course you do not want to store the password inside the token, the whole point of tokens is to avoid doing that. Passing passwords to an API all the time does increase the risk of them being stolen, tokens are much better for this.

Finally, the tokens expire after a time you control, usually they are short lived so even if someone does get their hands on one they will not last long.

If you take care of how you pass the tokens, meaning in the Authorisation Header over an https call then you are as protected as you can be and the headers will be encrypted. The point here is to never issue calls like this over basic http.

The author of the article you referenced is a well respected authority in this particular area and currently a Microsoft MVP and you are basically in good hands. Keep reading his articles, but pay attention to the details.

----------- Clarification related to JWT format --------------

yes the JWT token will contain information related to its issue date and expiry date as well. I have an article of my own on this : https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/

Look at the calls which create the token and look at the information returned in the screenshots.

In my example the token contains the actual encrypted token, the token type, seconds it expires in, the audience which is the ClientID, when it was issued and when it expires.

This is just an example of a token, yours will look probably a bit differently but you get the idea I hope. Use Postman to see what's coming back in the token

There are a number of concepts to be understood when it comes to OAuth2, it does require a bit of research and practice.

In short, you request a token with A Basic Authorisation Header, you get the token back and it's telling you what type it is, in my case it's Bearer so that's my next Authorisation Header for any call to a protected resource.

My suggestion is to start small, one step at a time, use Postman to build your calls and understand what's going on. Once you have that knowledge it's much easier to progress. Took me about 6 weeks to wrap my head around all concepts and get something working first time around, but now it takes a couple hours at most. Good luck

这篇关于如何在基于令牌的机制中验证访问令牌以访问受保护的资源?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！