Various Azure services allow you to authenticate using 2 different ways, some sort of password-based authN, and using Entra ID (formerly known as Azure Active Directory).
First a bit of history: When storage accounts were released back in 2008/2009, you only had storage account keys (2 secrets), that you supplied per request. Then shared access signatures came out (where you derive a value from the secrets). Then AAD/Entra authN was introduced. Same for SQL database (and MySQL and PostgreSQL), where in early versions you had to pick an admin username and password, and later supported Entra authentication.
Now storing passwords for services is kind-of a bad thing: You need a different password/credential for each service you want to call. If your app calls storage, SQL, service bus, event hub, Key Vault, you have to store (and protect) 5 credentials. And if one of these credentials is compromised, you must rotate it for all callers. It’s in general messy.
If you on the other hand have an Entra credential (which still can be a username/password combo like in the example with client_id/client_secret), you still must protect that one. But if it’s compromised, you only rotate a single credential of a single app, all server-side ACLs remain as they are.
What’s even more important, if your app workload runs in the cloud, you can use “managed identity”, where you tie an Entra identity to the VM or web app or Kubernetes pod you’re running on, and your workload doesn’t have to store any cred at all. When you need a token, you just issue a token request to 169.254.169.254, say you need a token for PostgreSQL, and off you go.
If you don’t want to do Entra authN, just skip all the Entra bits in the blog article and just do your username/password thing like before…
However, I strongly recommend to use Entra authN. For example, in the words of the storage team:
For optimal security, Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests against blob, queue, and table data, whenever possible. Authorization with Microsoft Entra ID and managed identities provides superior security and ease of use over Shared Key authorization. src
Using Entra authentication at the first glance makes it more complex: You must create an Entra app (setup takes longer), and prior authenticating to the DB you need to request a token. However, once you figure out you must rotate creds, or one credential is compromized, our you want to audit which app did what, you certainly start to appreciate having not used the same PostgreSQL password for all your workloads.
Added a short section here:
)
