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

Question

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

我的web服务引擎和应用程序的用例：

我的web应用程序:客户将注册他们的应用程序，无论是SPA还是移动应用程序。他们将在注册时获得客户id。在SPA或移动应用程序的情况下，只有作为密钥的客户端id会被泄露，因此我只提供客户端id。

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

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

客户端1 : MyApp1

客户端 2 ： 我的应用2

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

MyApp2也是如此。

对于基于令牌的机制，我看到了许多问题，仅参考下面这篇文章:

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

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

我在这里真的很困惑。我知道访问令牌验证发生在 [授权属性] 中，但我不会不存储访问令牌，上面的教程如何验证访问令牌。

我的想法是，当访问受保护资源的请求到来时，访问令牌会根据webconfig中的机器密钥属性进行加密或解密，这就是访问令牌在[授权]属性中的验证方式，但我不确定这一点。

Answer 1

这是困扰我很久的事情之一

我不确定我是否理解你为什么举了两个应用程序的例子，但是令牌机制实际上很简单，但是当你使用owin和identity时，它有点黑箱

令牌不会存储在服务器或数据库的任何位置，登录时验证用户的身份是使用您的逻辑完成的，或者通常是黑框身份，这涉及验证安全密码等

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

当用户下次发送请求时，他应该传递令牌，您需要解密它并验证必要的内容（例如到期时间），所有这些通常都是在幕后完成的

只是一个有趣的说明：即使您完全更改了数据库，令牌仍然对新数据库中甚至不存在的用户 ID 有效！但当然，当身份与安全邮票进行比较时，它会自动使这个令牌失效

Answer 2

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

当请求命中身份验证服务器（该服务器附加到 ConfigureOAuth（） 方法中的 Owin 管道）时，HTTP 标头令牌将被解密，并且令牌中的用户数据将位于上下文的当前用户。

Answer 3

您可以控制令牌内的信息。查看文章中的SimpleAuthorizationServerProvider类：

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

使用声明来存储您需要的关于用户、他们的用户名或角色的任何内容，这就是在您提到的文章中发生的事情。生成的令牌已经包含关于用户的信息。

这摘自文章：

第二个方法“GrantResourceOwnerCredentials”负责验证发送到授权服务器的令牌endpoint的用户名和密码，因此我们将使用前面创建的“AuthRepository”类，并调用方法“FindUser”来检查用户名和密码是否有效。

如果凭据有效，我们将创建“ClaimsIdentity”类并将身份验证类型传递给它，在我们的示例中是“bearer token”，然后我们将添加两个声明(“sub”、“role”)，这些声明将包含在签名的令牌中。您可以在这里添加不同的声明，但令牌大小肯定会增加。

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

最后，代币在你控制的时间之后到期，通常它们的寿命很短，所以即使有人真的拿到了一个代币，它们也不会持续很久。

如果您注意如何传递令牌，即在https调用的授权标头中，那么您将受到尽可能多的保护，标头将被加密。这里的重点是永远不要在基本的超文本传输协议上发出这样的调用。

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

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

是的，JWT令牌还将包含与其发行日期和到期日期相关的信息。对此我有一篇自己的文章:https://Eid and . com/2015/03/28/authorization-system-with-owin-we b-API-JSON-we b-tokens/

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

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

这只是令牌的一个例子，你的令牌看起来可能有点不同，但我希望你能明白。使用邮递员查看令牌中返回的内容

当涉及到OAuth2时，有许多概念需要理解，它确实需要一些研究和实践。

简而言之，你请求一个带有基本授权标头的令牌，你会得到令牌，它会告诉你它是什么类型，在我的情况下，它是承载，所以这是我对受保护资源的任何调用的下一个授权标头。

我的建议是从小处着手，一步一步来，使用Postman来建立您的呼叫，并了解正在发生的事情。一旦你有了这些知识，进步就容易多了。我花了大约6周的时间来理解所有的概念，并让一些东西第一次工作，但现在最多只需要几个小时。祝您好运