Fix , or work around, strange authorisation issue with `read_azure_table()`

[francisbarton]

Currently if one does

azkit::get_container()

it seems to work fine. azkit::get_auth_token() is called under the hood and this authorisation works, as far as we can see.

azkit::read_azure_table() has the same initial step under the hood to get a token, and it should use the same token already found and used above in get_container().

However we are generally finding that the httr2 call in azkit::read_azure_table() is failing.

One way round this is to pass force_refresh = TRUE, which starts a fresh manual authorisation process and generates a fresh token. However this is not ideal in terms of workflow! And it's not the "right" solution to the problem.

What we don't yet understand: what is it about the token that means it works fine for Azure blob storage authentication (for get_container, or read_azure_json) but not for Azure table storage authentication (for read_azure_table)?

We already have a slightly different process for authentication to table storage - from azkit::read_azure_table() :

access_token <- get_auth_token(...) |>
  purrr::pluck("credentials", "access_token")
headers <- list("2025-11-05", "application/json;odata=nometadata") |>
  purrr::set_names(c("x-ms-version", "Accept"))

resp <- httr2::request(table_ep) |>
  httr2::req_url_path_append(table_name) |>
  httr2::req_auth_bearer_token(access_token) |>
  httr2::req_headers(!!!headers) |>
  httr2::req_perform() |>
  httr2::resp_check_status()

but it does seem to be the initial token bit that is the problem. Once we refresh the token, the next steps with access token and setting headers work fine.

Another workaround would be to put a token$refresh()* step into azkit::read_azure_table(). From initial testing it seems like this solves the problem, though it feels very hacky.

* see ?AzureAuth::get_azure_token for details.

Other things we could consider would be using different default parameters in azkit::get_auth_token() (passed through to AzureAuth::get_azure_token(), such as:

• does it matter if we use version = 2 instead?
• we think resource = https://storage.azure.com is fine, but is there a better value that would make things work better with table storage? The resource argument is presented differently depending whether we are using AAD v1 or v2 (again see ?AzureAuth::get_azure_token for details).
• currently we set up client_id = NULL and use a sub-routine to get a client_id value but it looks like this is always the same value in all circumstances so it might be better to hardcode this and eliminate a potential problem area in the code.

See The-Strategy-Unit/nhp_tagged_runs_params#20
for discussion on auth still not working as expected in azkit::read_azure_table().

[francisbarton]

I just spent ages going round in circles on this because I couldn't get the token to authorise for azkit::read_azure_table() at all. Then I tried authenticating via MLCSU login and it was fine - I had been authenticating via my nhs.net login...