Cache Azure user delegation key for SAS signing

[emilk]

Rationale for this change

• closes Cache Azure user delegation key for SAS signing #800

AzureClient::signer() calls get_user_delegation_key() — a GetUserDelegationKey network round-trip (POST /?restype=service&comp=userdelegationkey) — on every signed_url / signed_urls call. A user delegation key is reusable until its expiry, so re-fetching it per request is wasteful and, under load, gets throttled by Azure (HTTP 503 ServerBusy).

Notably the other backends do not make an uncached network call while signing: the AWS signer signs locally from its cached credential, and GCP caches its signing credentials. Azure is the outlier — it makes a GetUserDelegationKey call on top of the already-cached AAD token.

We hit this in production: a workload issuing many presigned-URL requests against Azure Blob drove ~100k GetUserDelegationKey POSTs in 2h (~840/min), ~35% of which returned 503. The retry client backed off 10× (~10s) and then surfaced the error to the caller.

What changes are included in this PR?

Reuse the existing TokenCache<T> to cache the user delegation key on AzureClient:

• A long-lived key (12h) is fetched once and reused to sign many short-lived SAS tokens.
• TokenCache only returns a key with more than its min_ttl (2h here) remaining, so any SAS no longer than that is guaranteed to expire before its key (a SAS must not outlive the key it is signed with). The rare longer-lived SAS fetch a dedicated key.
• The cache entry expires when the key Azure actually granted does (SignedExpiry), not when we requested.
• Inherits TokenCache’s refresh-race double-check and fetch backoff.

TokenCache::with_min_ttl is extended to the azure-base feature so the Azure client can configure the cache (previously gated to aws-base/gcp-base).

The signed SAS tokens themselves are unchanged (still caller-specified expires_in).

Are there any user-facing changes?

No public API changes. Presigned-URL generation against Azure now performs far fewer GetUserDelegationKey requests.

Tests

Added azure::client::tests::test_delegation_key_expiry for the granted-vs-requested expiry parsing. The caching/refresh machinery itself is covered by the existing client::token tests.

Related issues / PRs

No existing issue tracks this specifically. Related:

• Azure Signed URL Support #101 — Azure Signed URL Support (closed): the feature that introduced Azure user-delegation-key SAS signing, i.e. the GetUserDelegationKey call this PR caches.
• feat: presigned URLs with extra query params and signed headers (SignedUrlOptions) #771 — presigned URLs with extra query params and signed headers (open): also touches the Azure presigning path (azure/mod.rs signed_url/signed_urls); orthogonal change, flagging for awareness of a possible minor merge interaction.

[alamb]

Notably the other backends do not make an uncached network call while signing: the AWS signer signs locally from its cached credential, and GCP caches its signing credentials. Azure is the outlier — it makes a GetUserDelegationKey call on top of the already-cached AAD token.

Agreed -- they use TokenCache

S3:

arrow-rs-object-store/src/aws/credential.rs

Line 759 in 09adc41

pub cache: TokenCache<Arc<AwsCredential>>,

GCP:

arrow-rs-object-store/src/client/mod.rs

Line 1053 in 09adc41

cache: TokenCache<Arc<T::Credential>>,

[alamb]

Thanks @emilk -- I went through this carefully and I think it makes sense to me

I left a few small comments but I don't think any of them are required for merge (we can do them as follow on PRs for example)

The one thing I would like to see before we merge this is some test of the actual flow (e.g. that cached credentials are actually fetched and reused). I took the liberty of pushing such a test -- please give it a look

Also, @kevinjqliu as our resident Azure expert, does this behavior make sense to you?

[alamb]

Can you add a URL that with some evidence for this claim? It seems this could be a good one

https://learn.microsoft.com/en-us/rest/api/storageservices/get-user-delegation-key#request-body

Start Required. The start time for the user delegation SAS, in ISO date format. It must be a valid date and time within seven days of the current date.

[alamb]

I think it would help to define SAS at least once (I realize it is used elsewhere in this module without that)

Suggested change

	/// The SAS tokens we sign with it stay short-lived; this only bounds how often
	/// The shared access signature (SAS) tokens we sign with it stay short-lived; this only bounds how often

[alamb]

I found the naming somewhat confusing here (as it wasn't clear to me what the relationship between get_user_delegation_key and fetch_user_delegation_key was (get and fetch are very similar). I wa sall the more confused because get actually does the network call, when I would normally exepct fetch to do that

Something like this might be easier to understand

• fetch_delegation_key --> get_delegation_key
• (current) get_delegation_key --> get_delegation_key_inner

[alamb]

I took the liberty of pushing the comment changes and function name changes. I'll plan to merge this once CI passes

Thanks @emilk

[kevinjqliu]

I verified this with my own azure storage account, it works great. Thanks for adding this!

I think there are a few follow-ups could make the delegation-key cache more flexible and robust:

• Make DELEGATION_KEY_VALIDITY optionally configurable so users can limit how long reusable keys remain valid. This setting should never shorten a key below the requested SAS lifetime.
• Remove the fixed DELEGATION_KEY_MIN_TTL. Azure returns the key’s actual SignedExpiry, so cache it and reuse the key only when SignedExpiry is later than the requested SAS expiry. Otherwise, fetch a new key.
• Treat Azure’s returned SignedStart and SignedExpiry as authoritative. Return a clear error if they are malformed or do not cover the full SAS lifetime.

EDIT: tracking as #807