Aad Certificate
You set up an aad certificate by uploading a public key to your directory app. Your workload then uses the matching private key to log in and get tokens. Teams often use this method so services can talk to cloud resources without passwords. Still, teams often grant broad directory roles to these apps to speed up setup. When a single app holds wide permissions, any leaked private key puts data at risk. How an aad certificate works in practice In Microsoft Entra ID, formerly Azure Active Direct
Certificate-Based Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an aad certificate by uploading a public key to your directory app. Your workload then uses the matching private key to log in and get tokens. Teams often use this method so services can talk to cloud resources without passwords. Still, teams often grant broad directory roles to these apps to speed up setup. When a single app holds wide permissions, any leaked private key puts data at risk.
How an aad certificate works in practice
In Microsoft Entra ID, formerly Azure Active Directory, apps need a way to prove identity. Passwords and client secrets are hard to keep safe because humans can read them. An aad certificate replaces those shared text secrets with a public and private key pair. You generate the key pair on a secure machine or inside a managed key vault. Then, you upload only the public half to the app record in the directory. The private key stays locked inside the server or container that runs your code.
When your app needs to read a database or call an API, it starts a login flow. The app creates a signed request using its local private key and sends it out. The directory checks this signature against the public key you uploaded earlier. If the math matches, the directory sends back an access token for that session. The app then passes this token to the target service to prove its identity. At no point does the private key travel across the network during this login check.
Why teams choose keys over client secrets
Text secrets often end up in source code, build logs, or local text files. Once a developer copies a secret to test a feature, you lose track of it. Key pairs reduce this risk when you store the private key in hardware or vaults. Many cloud setups let a virtual machine sign requests without exposing the raw key file. Even if an attacker reads the app memory, pulling the private key remains hard.
Still, managing the life cycle of these keys takes constant work from your team. Every key has an expiration date that will break your app if you miss it. You must build a process to create a new key pair before the old one dies. Next, you upload the new public key while the old one is still active. Once the app switches to the new private key, you delete the old public record. If a team forgets a single step, production jobs fail without warning at midnight.
Certificate-Based Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory roles solve and what they leave open
Using a key pair gives you strong proof of which app is logging in. Combined with role assignments, it controls which servers or databases the app can reach. This native setup stops unknown machines from getting tokens to your internal systems. It solves the initial login step and keeps plain text passwords out of your code.
Yet this setup only checks identity at the moment the app asks for a token. Once the app holds a valid token, the directory steps out of the way. The directory does not see the actual queries or commands the app sends in flight. If an app has permission to read a database, it can pull every row by default. Native roles cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. They also cannot block a destructive command if the role allows write actions. You know which app logged in, but you lack control over individual requests.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do I rotate an expiring key without downtime?
Upload the new public key to the app record before the current one expires. Update your workload to sign login requests with the new private key, then remove the old key.
Where should my team store the private key?
Store the private key in a managed cloud key vault or hardware module. Avoid placing raw key files in source control, container images, or shared team folders.
Can two apps share the same key pair?
While the directory allows it, sharing keys across apps is a bad practice. Give each app its own key pair so you can revoke one without breaking others.