Every storage account has two access keys, key1 and key2. Either key gives full control of all data in the account, like a root password, which is why sharing keys with applications or partners is risky: you cannot limit what the holder does, which container they touch or how long they keep access. Shared access signatures (SAS) exist so you can hand out limited, time-bound access instead, and Microsoft Entra ID authorization with data-plane roles is better still wherever the client can use it. A SAS is a URI (uniform resource identifier) with a set of query parameters and a signature. The parameters describe what is allowed: which services and resource types, which permissions (read, write, delete, list, add, create), start and expiry times, optionally allowed IP addresses and whether only HTTPS is permitted. The signature proves the token was created by someone holding a secret. Anyone holding the URI can use it until it expires, so treat it like a password: use short expiry times, grant the fewest permissions, and require HTTPS. In the portal you create one under Security + networking > Shared access signature (account level) or from a container's Shared access tokens menu, and from the CLI with commands such as az storage blob generate-sas.
Keep reading for free
Create a free StudyToCert account to read the rest of this lesson: 7 more sections, 6 key terms, a real-world example, an exam tip and self-check questions. Every lesson, lab and practice test is free with an account.