Azure B2C刷新令牌中过期字段的疑问与解析

我在.NET Core Web API项目中使用Azure B2C进行身份认证，按照官方文档的刷新令牌流程实现，通过RestSharp发送的请求代码如下：

var request = new RestRequest();
request.Method = Method.Post;
request.AddHeader("content-type", "application/x-www-form-urlencoded");
request.AddParameter("grant_type", "refresh_token", ParameterType.GetOrPost);
request.AddParameter("client_id", CLIENT_ID_HERE, ParameterType.GetOrPost);
request.AddParameter("scope", "CLIENT_ID_HERE offline_access", ParameterType.GetOrPost);
request.AddParameter("refresh_token", OLD_REFRESH_TOKEN, ParameterType.GetOrPost);

成功获取的响应如下：

{
    "access_token":"eyJhbGciOiJSUzI1NiIsImtp......",
    "id_token":"eyJhbGciOiJS......",
    "token_type":"Bearer",
    "not_before":1720104657,
    "expires_in":3600,
    "expires_on":1720108257,
    "resource":"guid-here",
    "id_token_expires_in":3600,
    "profile_info":"eyJ2ZXIiO.........",
    "scope":"B2C_Client_Id offline_access openid",
    "refresh_token":"eyJraWQiOiJjcGltY29yZ...........",
    "refresh_token_expires_in":76887
}

响应中的refresh_token_expires_in、expires_on等参数未在官方文档中提及，我有以下疑问：

• 刷新令牌默认过期时间为14天，可延长至90天，但refresh_token_expires_in的值为秒数而非Unix时间戳，这是否正确？
• expires_on的值是Unix时间戳，转换后对应54天，这是什么的过期时间？
• 我推测刷新令牌14天或90天的过期时间仅存在于B2C设置中，不会在响应的refresh_token_expires_in字段体现，请问该结论是否正确？

疑问解答 #

1. refresh_token_expires_in字段格式正确性
   这个字段格式是正确的，它表示当前返回的新刷新令牌的剩余有效时长（秒）。Azure B2C令牌响应中，所有*_in结尾的字段都是以秒为单位的相对过期时长，比如expires_in对应access_token的剩余有效秒数，id_token_expires_in对应id_token的剩余有效秒数，refresh_token_expires_in遵循同样规则。

2. expires_on字段的含义
   expires_on是Unix时间戳，它表示的是access_token的绝对过期时间。你转换后得到54天是异常的，正常情况下access_token默认有效期为1小时（3600秒），和响应中的expires_in值对应。出现这个问题大概率是转换时的时间戳单位错误——Unix时间戳通常是秒级，若误按毫秒级转换，就会得到远超实际的时间。你可以用not_before（令牌生效时间）加上expires_in（3600秒），验证是否和expires_on匹配，以此确认转换逻辑是否正确。

3. 关于刷新令牌设置的过期时间是否体现在响应中
   你的结论是正确的。Azure B2C后台设置的14天/90天是刷新令牌的最大生命周期（滚动过期），这个值不会直接返回在响应里。响应中的refresh_token_expires_in只是当前这个刷新令牌的剩余有效时长，每次刷新令牌时，新的刷新令牌会重置这个时长（但不会超过后台设置的最大生命周期）。一旦用户超过设置的天数未使用刷新令牌，或刷新次数达到限制，刷新令牌就会失效，无法再获取新的令牌。

内容的提问来源于stack exchange，提问作者abhilashca