Bearer token 重新部署后失效答案

【问题标题】：Bearer token become invalid after redeployBearer token 重新部署后失效
【发布时间】：2015-09-21 04:33:35
【问题描述】：

我们有 ASP.NET MVC 5.x WebAPI 2.x Web 应用程序作为 Azure 云服务运行，并使用令牌授权对我们的服务进行 REST API 调用。

问题是：每次我们重新部署应用时 - 所有当前令牌都变得无效（服务器对任何请求都返回“未授权”响应）。

问题是：为什么会发生以及如何防止这种行为？

更新：下面是颁发令牌的代码：

public string GetOAuthToken(IUser user) {
    if (user  != null) {
        var identity = new ClaimsIdentity(Startup.OAuthOptions.AuthenticationType);
        identity.AddClaim(new Claim(ClaimTypes.Name, user.UserName));
        identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, user.Id));
        AuthenticationTicket ticket = new AuthenticationTicket(identity, new AuthenticationProperties());
        var currentUtc = DateTime.UtcNow;
        ticket.Properties.IssuedUtc = currentUtc;
        ticket.Properties.ExpiresUtc = currentUtc.Add(TimeSpan.FromDays(36600)); //About 100 years
        string AccessToken = Startup.OAuthOptions.AccessTokenFormat.Protect(ticket);
        return AccessToken;
    }
    return "";
}

UPD2：似乎默认令牌端点（/Token）生成的令牌在重新部署后不会变得无效 - 所以问题（我认为）出在我们为“手工”令牌设置的一些属性中。在哪里可以找到创建默认令牌（由 /Token 端点返回）的代码？

【问题讨论】：

代币发行者是谁？您重新部署的相同 MVC / WebAPI 应用程序？此外，如果您使用 OWIN 作为后端，您可以插入中间件事件以检查发生这种情况的原因。如果令牌发行者在同一个部署中，则可能会在部署时发生某些变化。如果没有重现您的问题的确切步骤，我们将无能为力。
是的，发行者是同一个应用程序。我已经用代码 sn-p 更新了原始问题。是的 - 使用了 OWIN。你能建议在哪里“插入”以检查会发生什么吗？
注意：令牌的到期日期设置为今天+100 年 - 只是为了确保问题与令牌到期无关。

标签： asp.net asp.net-mvc azure asp.net-web-api

【解决方案1】：

不是一个完整的答案，但现在我们至少知道了这种行为的原因。

问题在于我们云服务的暂存/生产部署。我们将服务部署到暂存中，然后进行交换。在那一刻，在先前部署中发布的令牌变得无效。如果我们第二次这样做（部署到 staging 相同的版本然后交换） - 它再次变得有效。因此，显然任何发行的令牌都包含与当前运行服务的系统（真实或虚拟）的一些链接。

剩下的主要问题是：是否可以删除该链接或以某种方式控制它？

【讨论】：

【解决方案2】：

问题解决了。看来，默认创建的 AccessTokenFormat 使用 machineKey 来生成令牌。显然，这些密钥对于生产和暂存 VM 是不同的。解决方案相当简单。您需要生成自己的机器密钥并将其添加到项目的 Web.Config 文件中：

  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" relaxedUrlToFileSystemMapping="true" />

    <machineKey
      validationKey="YOUR VALIDATION KEY GOES HERE"
      decryptionKey="YOUR DECRYPTION KEY GOES HERE"
      validation="SHA1" decryption="AES"
    />

有关此方法的更多信息，您可以阅读本文的“第 5 步...”部分： http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/

【讨论】：

根据经验，我认为框架定位似乎对 FormsAuthentication.Decrypt 有影响。除了在部署之间同步machineKey，我还建议在部署之间保持compilation 和httpRuntime 同步，尤其是targetFramework。如果尽管添加了machineKey 节点，您的身份验证令牌仍拒绝在机器之间传输，这可能就是原因。