Question

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

使用我的网络服务引擎和我的应用程序：

我的网络应用程序：客户将注册其应用程序SPA或移动应用程序。他们将在注册时获得客户端ID。在SPA或移动设备的情况下，仅作为密钥的客户端ID将受到损害应用程序，因此我只是提供clientid。

Web服务引擎：在登录客户的各个应用程序后，支持多个客户端管理每个用户的会话。

因此，假设有2个客户将他们的应用程序注册到我的Web应用程序中：

客户端1：MyApp1

客户端2：MyApp2

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

MyApp2也是如此。

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

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

但是上面教程和大多数教程中唯一的混淆部分是在验证用户名和密码并生成访问令牌之后。上面的教程是否在服务器端cookie中存储访问令牌，以便在请求访问受保护资源时验证accessstoken？

我真的很困惑。我知道在[Authorize属性]中发生了accessstoken验证，但我没有在没有存储accessstoken的情况下得到如何在教程上验证accessstoken。

我的想法就像可能是当访问受保护资源的请求时，访问令牌是基于webconfig中的机器密钥属性加密或解密的，这就是在[Authorize]属性中验证访问令牌的方式，但我只是不确定这个

Answer 1

您可以控制令牌内的信息。请查看文章中的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”，然后   我们将添加两个声明（“子”，“角色”），这些声明将包括在内   签名令牌。您可以在此处添加不同的声明，但令牌大小   肯定会增加。

这就是为什么您不需要将令牌存储在任何位置，令牌是自包含的，并且所有内容都以加密形式存储在其中。不要忘记，在添加包含您已验证用户名和密码的用户名的声明之前，您可以保证为有效的用户/密码组合正确创建令牌。当然，您不希望将密码存储在令牌内，令牌的整个要点是避免这样做。将密码始终传递给API会增加被盗的风险，令牌也更好。

最后，令牌在你控制的一段时间后到期，通常它们是短暂的，所以即使有人拿到手也不会持续很长时间。

如果你负责如何传递令牌，这意味着在https呼叫的授权标题中，那么你就像你一样受到保护并且标题将被加密。这里的要点是永远不要在基本的http上发出这样的调用。

您引用的文章的作者是这一特定领域备受尊敬的权威，目前是Microsoft MVP，您基本上处于良好的状态。继续阅读他的文章，但要注意细节。

-----------与JWT格式相关的澄清--------------

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

查看创建令牌的调用并查看屏幕截图中返回的信息。

在我的示例中，令牌包含实际的加密令牌，令牌类型，它到期的秒数，作为ClientID的受众，发布时间以及到期时间。

这只是一个令牌的一个例子，你的看起来可能有点不同，但你得到了我希望的想法。使用邮递员查看令牌中的内容

OAuth2涉及到许多概念，需要进行一些研究和实践。

简而言之，您使用A Basic Authorization Header请求令牌，您将获得令牌并告诉您它是什么类型，在我的情况下它是Bearer，因此这是我对受保护资源的任何调用的下一个Authorization Header。 / p>

我的建议是从小开始，一步一步，使用邮差建立你的电话，并了解正在发生的事情。一旦掌握了这些知识，就会更容易进步。花了我大约6个星期的时间围绕所有概念，让我的第一次工作变得有效，但现在最多需要几个小时。祝你好运

Answer 2

应用程序不需要存储访问令牌服务器端，它只会从传递的令牌中读取用户。

当请求到达认证服务器时，该服务器附加到ConfigureOAuth（）方法中的Owin管道， HTTP标头令牌被解密，来自令牌的用户数据坐落到上下文的当前用户。

Answer 3

这是困扰我很长时间的事情之一

我不确定我理解为什么你为2个应用程序提供了一个例子，但令牌机制实际上很简单，但当你使用owin和identity时，它有点黑盒子

令牌未存储在服务器或数据库的任何位置，在登录时对用户进行身份验证是使用您的逻辑完成的，或者通常再次使用黑盒子标识，这涉及验证安全密码等

在此之后生成令牌（通常使用身份）或者如果您手动执行此操作，这将涉及使用您要存储在其中的任何信息来保护令牌

当用户下次应该传递令牌时发送请求并且您需要解密它并验证必要的内容（例如过期时间），所有这些都是在场景后面完成的 p>

只是一个有趣的注意事项：即使您完全更改了数据库，令牌仍然有效，用户ID甚至不存在于您的新数据库中！但是，当与securityStamp

进行比较时，身份会自动使此令牌无效

如何验证访问令牌是否可以在基于令牌的机制中访问受保护资源？

3 个答案: