刷新IdentityServer4客户端中的访问令牌

问题描述

我想知道如何使用混合流(它是使用ASP.NET Core MVC构建的)在IdentityServer4客户端中刷新访问令牌.

I wonder how to refresh a access token in a IdentityServer4 client using the hybrid flow and which is built using ASP.NET Core MVC.

如果我正确理解了整个概念，那么客户端首先需要具有"offline_access"作用域才能使用刷新令牌，这是启用短期访问令牌和撤销刷新令牌的能力的最佳做法，以防止出现任何新情况访问要发行给客户端的令牌.

If I have understood the whole concept correctly the client first need to have the "offline_access" scope in order to be able to use refresh tokens which is best practice to enable short lived access tokens and ability to revoke refresh tokens preventing any new access tokens to be issued to the client.

我成功获得了访问令牌和刷新令牌，但是我应该如何在MVC客户端中处理访问令牌的实际更新过程?

I successfully get a access token and a refresh token, but how should I handle the actual update procedure of the access token in the MVC client?

OpenId Connect(OIDC)中间件可以自动处理吗?还是我应该在每次调用WEB Api的地方都检查访问令牌的过期时间，方法是基本上检查访问令牌是否已过期或即将过期(即将到来的30秒)，然后通过使用刷新令牌调用令牌端点来刷新访问令牌?

Can the OpenId Connect (OIDC) middleware handle this automatically? Or should I rather check the expire time of the access token everywhere I call WEB Api's by basically check if the access token have expired or will expire very soon (upcoming 30 seconds) then refresh the access token by calling the token endpoint using the refresh token?

是否建议在我的Controller操作中使用 IdentityModel2 库TokenClient扩展方法RequestRefreshTokenAsync令牌端点的调用方法?

Is it recommended to use the IdentityModel2 library TokenClient extension method RequestRefreshTokenAsync in my Controller action methods for calling the token endpoint?

我看到了一些代码，这些代码在OIDC中间件事件中请求访问令牌，并使用响应存储一个包含到期日期时间的声明.问题在于我的OIDC已经以某种方式自动请求了访问令牌，因此在收到第一个令牌之后直接请求新的访问令牌感觉不太好.

I have seen code that in the OIDC middleware events request access token and using the response store a claim containing a expire datetime. The problem is that my OIDC in somehow already request a access token automatically so it doesn't feel good to request a new access token directly after recieving the first one.

控制器"操作方法示例没有访问令牌刷新逻辑:

Example of a Controller action method without access token refresh logic:

public async Task<IActionResult> GetInvoices()
    {
        var token = await HttpContext.Authentication.GetTokenAsync("access_token");

        var client = new HttpClient();
        client.SetBearerToken(token);

        var response = await client.GetStringAsync("http://localhost:5001/api/getInvoices");
        ViewBag.Json = JArray.Parse(response).ToString();

        return View();
    }

推荐答案

OIDC中间件将不为您解决这个问题.它在检测到HTTP 401响应时正在执行，然后将用户重定向到IdentityServer登录页面.重定向到您的MVC应用程序后，它将把声明转换为ClaimsIdentity并将其传递给Cookies中间件，该中间件将具体化为会话cookie.

The OIDC middleware will not take care of this for you. It's being executed when it detects a HTTP 401 response, it then redirects the user to IdentityServer login page. After the redirection to your MVC application, it will turn claims into a ClaimsIdentity and pass this on to the Cookies middleware which will materialise that into a session cookie.

只要cookie仍然有效，其他所有请求都将不涉及OIDC中间件.

Every other request will not involve the OIDC middleware as long as the cookie is still valid.

因此，您必须自己照顾这一点.您要考虑的另一件事是，每当您要刷新访问令牌时，都必须更新现有令牌，以免丢失它.如果不这样做，则会话cookie将始终包含相同的令牌(原始令牌)，并且每次都会刷新.

So you have to take care of this yourself. Another thing you want to consider is that whenever you're going to refresh the access token, you'll have to update the existing one so you don't lose it. If you don't do this, the session cookie will always contain the same token - the original one - and you'll refresh it every time.

我发现的一个解决方案是将其挂接到Cookies中间件中.这是一般流程:

A solution I found is to hook that into the Cookies middleware.Here's the general flow:

• 在每个请求上，使用Cookies中间件事件检查访问令牌
• 如果已接近到期时间，则请求一个新的
• 替换ClaimsIdentity
中的新访问令牌和刷新令牌
• 指示Cookies中间件更新会话cookie，使其包含新令牌

• On every request, use the Cookies middleware events to inspect the access token
• If it's close to its expiration time, request a new one
• Replace the new access and refresh tokens in the ClaimsIdentity
• Instruct the Cookies middleware to renew the session cookie so it contains the new tokens

我喜欢这种方法的地方是，在您的MVC代码中，几乎可以保证始终有一个有效的访问令牌，除非刷新令牌使行连续失败多次.

What I like with this approach is that in your MVC code, you're pretty much guaranteed to always have a valid access token, unless refereshing the token keeps failing several times in a row.

我不喜欢它与MVC紧密相关-更具体地说是Cookies中间件-因此它不是真正可移植的.

What I don't like is that it's very tied to MVC - more specifically the Cookies middleware - so it's not really portable.

您可以查看此GitHub存储库我放在一起.它确实使用IdentityModel，因为它可以处理所有事情，并且隐藏了您必须对IdentityServer进行的HTTP调用的大部分复杂性.

You can have a look at this GitHub repo I put together. It indeed uses IdentityModel as this takes care of everything and hides most of the complexity of the HTTP calls you'd have to make to IdentityServer.

这篇关于刷新IdentityServer4客户端中的访问令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！