asp.net - 为什么要在 OAuthAuthorizationServerProvider.GrantRefreshToken 中添加声明？

Question

我正在使用不记名 token 为 OAuth 2 配置 AspNet.Identity，我看到了多个实现 OAuthAuthorizationServerProvider.GrantRefreshToken 方法的示例，作者在其中演示了向 new ClaimsIdentity 如下所示。

我试图在我的单服务器(即我的 Web API 项目既是授权服务器又是资源服务器)的上下文中理解这一点，如有必要，我可能会在以后拆分成单独的服务器。

public override Task GrantRefreshToken(OAuthGrantRefreshTokenContext context)
{
    var originalClient = context.Ticket.Properties.Dictionary["as:client_id"];
    var currentClient = context.ClientId;

    if (originalClient != currentClient)
    {
        context.SetError("invalid_clientId", "Refresh token is issued to a different clientId.");
        return Task.FromResult<object>(null);
    }

    // Change auth ticket for refresh token requests
    var newIdentity = new ClaimsIdentity(context.Ticket.Identity);

    // CONSIDER: I don't know why you would add a claim here, but here's an example.
    //var newClaim = newIdentity.Claims.Where(c => c.Type == "newClaim").FirstOrDefault();
    //if (newClaim != null)
    //{
    //    newIdentity.RemoveClaim(newClaim);
    //}
    //newIdentity.AddClaim(new Claim("newClaim", "newValue"));

    var newTicket = new AuthenticationTicket(newIdentity, context.Ticket.Properties);
    context.Validated(newTicket);

    return Task.FromResult<object>(null);
}

The documentation状态:

“应用程序必须调用 context.Validated 以指示授权服务器中间件根据这些声明和属性颁发访问 token 。”

我不明白这个。我以为我们分发的是刷新 token ，而不是访问 token 。

此外，“可以为 context.Validated 调用提供不同的 AuthenticationTicket 或 ClaimsIdentity，以控制哪些信息从刷新 token 流向访问 token 。”

我认为所有声明都存储在我签名和加密的访问 token 中，该 token 作为 Authorization: Bearer XXXXXX 传递。但是，我对 ClaimsIdentity 和 AuthenticationTicket 与我的 OAuth 2.0 流程中的任何内容的实际关系有一个微弱的把握。

我最好的猜测是 GrantRefreshToken 需要采用已经过身份验证和授权的身份 (context.Ticket.Identity) 并验证是否应向其添加刷新 token 通过调用 context.Validated。

Answer 1

OAuth2 中的刷新 token 只是另一种类型的授权:另一种获取新 access_token 的方法。

因此，必须验证 RefreshToken 才能为用户发出新的 access_token。

当将刷新 token 持久保存到底层存储(例如数据库)时，整个用户身份必须与其一起存储(通常使用 AuthenticationTokenCreateContext 的 SerializeTicket() 方法> 对象)。这意味着在第一个 access_token 生成期间获取的声明中的任何更改都不会传播到默认情况下使用 RefreshToken 授予的其他 access_token 排放(如果您需要在 access_token 中更新这些声明，则需要重新加载它们)。

我相信这是许多示例展示如何在 GrantRefreshToken 方法中添加/替换新身份声明的主要原因。

我将尝试进一步阐明支持 RefreshTokenGrant 时通常会发生什么:

1. 用户使用任何类型的受支持授权(例如 ResourceOwnerCredentials)对自己进行身份验证；
2. 我们创建一个绑定(bind)到这个特定用户的身份(我们可以在此时添加声明)并使用它来创建一个新的 AuthenticationTicket(我们通过调用 Validated(ticket) 在特定的 context 对象上)将用于创建 access_token;
3. 框架在提供的 IAuthenticationTokenProvider 上生成调用 CreateAsync 的新刷新 token 。在这个方法中，我们必须检索票并将其与唯一的 Id 和一些有用的元数据一起存储到某种持久性存储(例如数据库)中。这个Id就是用户角度的refresh_token。
4. 我们向用户返回 access_token(其中包含用户的序列化声明)和 refresh_token(仅供引用)。
5. 一段时间后，用户必须再次进行身份验证(例如 access_token 过期)，因此他将使用 refresh_token 向 Token 端点发送请求。
6. 我们从持久存储中检索refresh_token 记录并反序列化将用于创建新身份的票证。此票证包含我们在第一次身份验证时添加的所有声明(这几乎是第一个 access_token 的精确副本):如果这些声明中的任何一个在当前时刻和第一次身份验证之间的时间间隔内发生变化(例如，向用户添加了新角色，电子邮件已更改等)我们现在有机会修改新身份并添加/替换这些声明，以便新的 access_token 将反射(reflect)更改.
7. 流程继续验证票证(和以前一样)并生成一对 access_token 和 refresh_token 发送给用户。