【问题标题】:How is the OWIN OAuth 2 token actually created?OWIN OAuth 2 令牌是如何实际创建的?
【发布时间】:2014-12-28 00:51:14
【问题描述】:

我们有 OWIN OAuth 2.0 工作(感谢 this fantastic post),但需要更深入地了解在 HTTP 响应中将 ClaimsIdentity 转换为实际 access_token 字符串的实际过程。

我们正在 OAuth 授权提供程序中的这个方法中创建 ClaimsIdentity

public class SimpleAuthorizationServerProvider : OAuthAuthorizationServerProvider
{
    // <snip>
    public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
    {
        // validation, user checking code here

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

当我们将 HTTP POST 请求设为grant_type=password&amp;username=user007&amp;password=jamesbond(放心,这里的密码就可以了),我们得到了 HTTP POST 响应体

{"access_token":"9K8VtOBseU0-XZfdGe2_urn2HESY3jLkpgvowOQFPXsHeWNOrTlTVzfPu35ZEvr4AqSj_b0laesBegtVWuR8R-aItnNXw4vXiuCg0cTNMUKP_yfi89VhD446o2X6ffL8upwZVILpomweSweIVlDmwUDzIwf1ZqubrQ8vuiQDFu-_7vpjPwJ5yVvomQ75agsJWMZk-H_bVWSObds82aM8LCRJwb2bUJchr6_L1GP8xdXqRQz24uDhHvco-XByyMSMzZm-Qo0VVBbocbgP64OJulbihVG_W9e8G69UfbX99pIYiLyE4jixiUtjOKSiMYBISW3_fg","token_type":"bearer","expires_in":1799,"as:client_id":"","userName":"user007",".issued":"Fri, 31 Oct 2014 16:02:05 GMT",".expires":"Fri, 31 Oct 2014 16:32:05 GMT"}

问题:创建实际access_token 字符串的逻辑是什么?

问题中的一些具体问题

  1. access_token 字符串的内部结构是什么?
  2. 它是加密的还是签名的或两者兼而有之?使用的密钥是什么(假设 IIS/Azure 云服务)?
  3. 我们如何覆盖生成实际发送出去的字符串的实现,然后在后续访问中检查相同的令牌/字符串?

谢谢

【问题讨论】:

    标签: asp.net authentication asp.net-web-api oauth owin


    【解决方案1】:

    很高兴我的帖子很有用,请按以下方式找到答案:

    1 - 这个“神奇”字符串是一个加密的签名字符串(poor MSDN documentation,表示加密或签名不清楚),其中包含所有的反序列化版本已登录用户的声明和票证属性。如果在 IIS 模式下,加密/签名是通过 ma​​chineKey 节点 (documentation) 中的“decryptionKey”和“validationKey”键值完成的。如果作为独立的 OWIN 应用程序运行,则加密使用旧版 DPAPI 来保护它,并且实际上使用过时的 3DES 算法 (documentation)。它的默认实现在source code here

    2 - 在第 1 点中回答。

    3 - 检查我的 new post,我在其中展示了如何发布签名的 Json Web 令牌而不是默认访问令牌。

    希望这能回答你的问题。

    【讨论】:

    • 对于自定义令牌的第三点,如果实现自定义CustomTokenFormat : ISecureDataFormat&lt;AuthenticationTicket&gt; 并将其提供给OAuthAuthorizationServerOptionsAccessTokenFormat 属性,如何在访问时强制执行它的验证?通过向UseOAuthAuthorizationServer(..)UseOAuthBearerAuthentication(..) 提供相同的OAuthAuthorizationServerOptions 对象(因此相同的AccessTokenFormat)会自动发生这种情况吗?
    • 你是对的,这是自动发生的。访问令牌的到期时间是通过在OAuthAuthorizationServerOptions 中使用属性AccessTokenExpireTimeSpan 设置的,那么这将是AuthenticationTicket 数据属性的一部分,您可以在其中读取AccessTokenFormat 的自定义类中的ExpiresUtc 属性,你可以在这里查看:link
    • @Taiseer 解密密钥/验证密钥如何与多个服务器实例前的负载均衡器一起工作?
    • @VictorMukherjee - 你有没有找到这个问题的答案。这正是我想要理解的......我们正在使用托管在 Windows azure 上的多个服务器实例,如果负载均衡器将请求发送到不同的机器,访问令牌是否仅在创建它的服务器上有效?
    猜你喜欢
    • 2015-06-15
    • 2014-10-05
    • 1970-01-01
    • 2021-05-04
    • 2023-03-05
    • 1970-01-01
    • 1970-01-01
    • 2021-04-26
    • 1970-01-01
    相关资源
    最近更新 更多