You can think of an Azure storage account as an administrative envelope encompassing blob containers, file shares, queues, and tables. Like other Azure resources, access happens in either the control or management plane and the data plane. Typically, users access a storage account through the control plane to administer its resources, while applications and services go through the data plane to access the resources' contents. These two modes aren't mutually exclusive, as users can write and read data, and applications can perform some administrative functions. Unless I state otherwise, the authentication and authorization methods discussed here apply to both users, applications, and services. 

There are three methods to authenticate and authorize a storage account, irrespective of going through the control or data plane. Access keys, shared access signatures, and role-based access control form a hierarchy. Access keys are analogous to an admin account with global access to all resources in the storage account through to shared access signatures and RBAC allowing permissions to be set on individual objects. Access keys and shared access signatures take a "set and forget" approach in that you give out a key for users and applications to access storage resources. The key or signature is entirely self-contained, specifying authentication and authorization information. Revoking access is problematic for both of these methods. On the other hand, RBAC enables easy ongoing permission management while offering a high level of permission control. All these methods have pros and cons that we'll discuss, but spoiler alert – RBAC is Microsoft's preferred option.