Azure Storage：如何解决Blob级SAS令牌偶发失效的时钟偏移问题

• 第一类报错（Signed expiry time must be after signed start time）的触发机制：当SAS令牌未显式设置StartsOn参数时，Azure存储服务端不会把令牌生成端的本地时间当隐式生效时间，而是把收到请求瞬间的服务端UTC时间作为隐式开始时间。如果生成端时钟比服务端时钟慢，基于本地慢时钟算出来的ExpiresOn（本地时间+1小时）值，在请求打到服务端时，可能已经比服务端当前时间还小，此时服务端会拿当前时间当开始时间，自然抛出“过期时间早于开始时间”的认证错误，和第一个报错的时间戳特征完全对应。
• 第二类报错（Signature not valid in the specified time frame）的触发机制：服务端时间是准确的，但生成端的系统时钟存在大幅漂移（比如虚机时钟停滞、时区配置错误），通过DateTime.UtcNow取到的时间值本身就是错的，算出来的ExpiresOn早就是过去的时间，客户端拿到令牌立即访问时，自然早就超出令牌的有效范围。
• 之前的操作误区：以为不设置开始时间就能规避时钟偏移，实际上这种做法完全没留时间缓冲，把时钟差的影响拉满——隐式开始时间完全由服务端实时时间决定，没有任何容错空间。

• 不要依赖SDK或服务端的隐式时间逻辑，显式设置带偏移缓冲的生效时间：把StartsOn设为当前UTC时间往前拨10~15分钟，覆盖正常的时钟偏移范围，避免因为生成端和服务端的时间差触发认证错误。
• 校验生成端的时间准确性：给部署应用的虚机开NTP时间同步，确保系统时钟和权威UTC时间源的误差在1分钟以内，避免因为系统时钟漂移生成已经过期的令牌。
• 严格校验传入SDK的时间值类型：设置StartsOn和ExpiresOn时，必须保证传入的DateTime的Kind属性是DateTimeKind.Utc，不要传带本地时区标记的时间值，否则SDK算签名的时候会把时区偏移量算进去，导致服务端校验签名时不匹配。
• 修正后的代码示例：

var blobSasBuilder = new BlobSasBuilder
{
    BlobContainerName = containerName,
    BlobName = fileName,
    Resource = "b",
    // 提前15分钟生效，抵消两端的时钟偏移
    StartsOn = DateTime.UtcNow.AddMinutes(-15),
    // 显式标记时间类型为UTC，避免SDK时区转换错误
    ExpiresOn = DateTime.SpecifyKind(DateTime.UtcNow.AddHours(1), DateTimeKind.Utc),
    Protocol = SasProtocol.Https
};

• 多实例部署的额外排查：如果应用跑在负载均衡后面的多实例集群里，要逐台检查实例的系统时钟同步状态，避免部分实例没开时间同步、生成带错时间的无效令牌。另外别用DateTime.Now（本地时区时间）代替DateTime.UtcNow算令牌有效期，这类错误通常会差出几个时区，必然导致令牌不在有效时间帧里。

关于v12 SDK的bug疑虑：目前这类偶发的时间类认证错误，绝大多数都是上述的时钟偏移、隐式时间逻辑、时间类型不匹配导致的，并非SDK本身的签名计算故障。如果按上述方式调整后仍有偶发报错，可以拆分生成的SAS令牌里的st（开始时间）、se（过期时间）参数值，和Azure服务端返回的Date响应头的时间值做差，就能快速定位是哪一端的时间存在偏差。

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