Storage Shared Key and SAS errors — KeyBasedAuthenticationNotPermitted, AuthenticationFailed and the SAS mismatch codes
Why a request signed with an account key or carrying a SAS token is refused — Shared Key disabled on the account (and the tools that still use it), SAS expired or not yet valid, signature mismatch from a rotated key, malformed or wrong-level SAS, missing permissions, services, resource types, IP or protocol, and the account's SAS expiration policy — each with the verbatim code, message and detail, cause, check and fix.
markdownreferencev114GH-95ZCstage: operatetrust: officialtrust: fieldservice: storageinterface: anyKeyBasedAuthenticationNotPermittedKey based authentication is not permitted on this storage account.AuthenticationFailedServer failed to authenticate the request. Make sure the value of the Authorization header is formed correctly including the signature.Signed expiry time has to be after signed start timeThe MAC signature found in the HTTP request is not the same as any computed signature.SAS field 'sv' is not well formed.The specified signed resource is not allowed for the this resource levelAuthorizationPermissionMismatch SAS spAuthorizationServiceMismatchThis request is not authorized to perform this operation using this service.This request isn't authorized to perform this operation using this service.AuthorizationResourceTypeMismatchAuthorizationSourceIPMismatchAuthorizationProtocolMismatchSAS expiredSAS clock skewSAS expiration policy Blockconnection string shared key disabledstorage_use_azureadaz storage --auth-mode key
Storage Shared Key and SAS errors
Shared Key and SAS requests carry their own signature, so they fail at the authentication gate with AuthenticationFailed (the detail line says why) or, when the account forbids keys, KeyBasedAuthenticationNotPermitted. A valid SAS can still fail authorization with an Authorization…Mismatch code naming the SAS field that doesn't cover the request. Entra ID, network and account errors: reference/storage/access-errors.md.
| Code / message | Cause → fix | Check |
|---|---|---|
403 KeyBasedAuthenticationNotPermitted Key based authentication is not permitted on this storage account. | allowSharedKeyAccess is false. Account keys, connection strings, service SAS and account SAS are all refused. Switch to Entra ID (and a user delegation SAS if a SAS is needed), or re-enable Shared Key | az storage account show -n <acct> --query allowSharedKeyAccess |
| Same, from a tool you didn't write | az storage … without --auth-mode login; the portal's Azure Files view; Terraform azurerm without storage_use_azuread = true (it provisions containers and blobs with Shared Key). Terraform's docs warn that not every storage operation supports Entra ID: one report shows queue properties still failing with the flag set | reference/storage/access-models.md; patterns/alternatives/terraform-azurerm.md |
403 AuthenticationFailed Server failed to authenticate the request. Make sure the value of the Authorization header is formed correctly including the signature. detail Signed expiry time … has to be after signed start time … | SAS expired, or its start time is in the future (clock skew up to 15 minutes). Omit the start time or set it 15 minutes in the past; leave margin on the expiry | se and st in the token |
Same, detail The MAC signature found in the HTTP request '…' is not the same as any computed signature. | Wrong or rotated account key, encoding damage, or a SAS signed with a key that has since been regenerated | Which key signed it; az storage account keys list (needs listKeys) |
Same, detail SAS field 'sv' is not well formed. | Hand-built SAS or a version mismatch | Generate it with the SDK or az storage … generate-sas |
Same, detail The specified signed resource is not allowed for the this resource level (sic) | A service SAS used for an account-level call such as listing containers | Use an account SAS, or a SAS for the container |
| A user delegation SAS stops working before its own expiry | Its user delegation key expired or was revoked (az storage account revoke-delegation-keys); every SAS signed with that key is invalid. Microsoft doesn't document the exact error | Key expiry (≤ 7 days) vs SAS expiry |
403 AuthorizationPermissionMismatch with a SAS | sp lacks a needed permission (r, w, d, l, …); overwriting needs write and delete. For a user delegation SAS, the signer's own data roles must also allow it | sp in the token; the signer's roles |
403 AuthorizationServiceMismatch This request is not authorized to perform this operation using this service. | Account SAS ss doesn't include this service (b, f, q, t) | ss |
403 AuthorizationResourceTypeMismatch | Account SAS srt doesn't include this level (service, container, object). The hub's reading from the code name and srt's meaning; no Microsoft page gives the message | srt |
403 AuthorizationSourceIPMismatch | The caller's public IP isn't in the SAS sip range (IPv4 only). Hub's reading, as above | sip vs the caller's public IP |
403 AuthorizationProtocolMismatch | SAS spr=https used over HTTP. Hub's reading, as above | Request scheme |
| 403 after a SAS expiration policy is set to Block | The SAS is valid longer than sasExpirationPeriod, or has no signed start (st is required under a policy). Applies to service and account SAS | az storage account show -n <acct> --query sasPolicy; reference/storage/sas.md |
Before re-enabling Shared Key to make an error go away, ask your human: it reopens every key-based path, including anyone with listKeys (Owner, Contributor). The durable fix is moving the client to Entra ID: guides/storage/access-blobs-from-typescript.md.