Entra ID vs. API Keys on Azure

Part of a series on running AI workflows across model providers — this one is about how DNotifier authenticates to your Azure resource, not just which deployment it calls.

DNotifier's Azure AI setup form, covered in Azure AI on DNotifier: Setup Guide, accepts two genuinely different authentication approaches: a simple API key, or Entra ID (Microsoft's identity platform, formerly Azure Active Directory)-style credentials. Neither is a trick option — each fits a real, different set of circumstances, and picking between them is worth a deliberate decision rather than defaulting to whichever one is faster to set up.

API keys: the simple path

An API key is exactly what it sounds like: a single secret string that authenticates requests against your Azure AI resource. It's fast to set up, easy to understand, and works fine for a huge range of legitimate use cases — internal tools, prototypes, small teams, and anything where the operational overhead of a more sophisticated identity system isn't worth the tradeoff.

The tradeoff is what you'd expect from any static secret: it doesn't expire on its own, it needs to be stored and rotated carefully, and if it leaks, whoever has it has full access until it's revoked. For a lot of teams and a lot of use cases, that's a manageable, acceptable risk. For others — larger organizations, regulated industries, or teams managing many resources across many people — it starts to feel thin.

Fast, simple, and appropriate for a real range of use cases — with the tradeoffs of any static secret.

Entra ID: identity-based access

Entra ID authentication ties access to actual identities — users, service principals, managed identities — governed by Azure's role-based access control (RBAC) system rather than a single shared secret. This means access can be scoped precisely (this service principal can call this specific resource, nothing more), rotated and revoked through identity management rather than secret rotation, and audited through Azure's centralized identity logging rather than tracking who has a copy of a key.

For managed identities specifically — where an Azure resource like a virtual machine or App Service authenticates as itself, with no secret to store or leak in the first place — this eliminates the static-secret risk entirely for that resource's calls.

Access tied to identity and governed by RBAC, rather than to possession of a shared secret.

What actually decides which one to use

The decision mostly comes down to organizational scale and regulatory context rather than technical capability — both approaches work, and DNotifier's sendAI() calls behave identically regardless of which one authenticates them underneath.

Smaller teams, prototypes, and internal tools without strict compliance requirements generally do fine with API keys — the operational simplicity is a real benefit, not a shortcut being taken irresponsibly. Larger organizations, anything touching regulated data, or any setup where multiple services or teams need differently-scoped access to the same Azure AI resources tend to benefit meaningfully from Entra ID's centralized, auditable access model.

A use case that shows the decision in practice

A small internal tools team started with an API key for a single Azure AI deployment powering an internal support-ticket triage agent, which was entirely appropriate for their scale — one team, one resource, low blast radius if something went wrong. As the same underlying deployment started getting called from three additional internal services built by different teams, each needing different scopes of access, the shared API key became a liability: any one team's leaked key would have exposed access for all of them, and there was no way to revoke one team's access without rotating the key for everyone. Migrating to Entra ID with separate managed identities per service let each team's access be scoped, audited, and revoked independently — solving a problem that scaling up the API key approach couldn't have solved cleanly.

Frequently asked questions

Does switching between API keys and Entra ID require code changes in a DNotifier-based integration?

The authentication method is configured in DNotifier's provider setup rather than in application code calling sendAI(), so switching doesn't require changes to the calls themselves — the setup configuration is what changes.

Is Entra ID always the more secure choice?

It offers stronger access control and auditability for multi-identity, multi-team scenarios, but a well-managed API key in a genuinely simple, single-team setup isn't insecure — the right choice depends on the actual access pattern, not a blanket security ranking.

Can a single Azure AI resource support both authentication methods for different callers?

That's an Azure-side RBAC and resource configuration question outside what this article's sourcing can confirm definitively — check Azure's current identity documentation for your specific resource configuration.

Is managed identity only available for Azure-hosted callers?

Yes, conceptually — managed identity is specifically for Azure resources authenticating as themselves, so it applies where the caller itself runs on Azure infrastructure.

The Bottom Line

Next in this series: closing out this batch by tying together everything covered so far across all seven providers — and why building on an orchestration layer rather than direct integrations continues to matter.

Read part ten: Avoiding Lock-In: Azure and Beyond. Explore dnotifier.com.