Ms Entra App
An ms entra app is an identity profile that lets services and users log in. You set it up by registering the tool in your directory and adding permissions. Many teams create one shared registration for all their internal tools and scripts. They often attach broad read and write roles so setups work on the first try. When those roles are too wide, one leaked secret puts many backend systems at risk. How an ms entra app works in your directory Every registration creates two separate parts insid
Microsoft Entra ID (Azure AD) + Per-App VPN: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An ms entra app is an identity profile that lets services and users log in. You set it up by registering the tool in your directory and adding permissions. Many teams create one shared registration for all their internal tools and scripts. They often attach broad read and write roles so setups work on the first try. When those roles are too wide, one leaked secret puts many backend systems at risk.
How an ms entra app works in your directory
Every registration creates two separate parts inside your identity directory. The first part is the global app object, which acts as a template. This template holds the name, logo, redirect links, and required API permissions. The second part is the local service principal, which lives inside a specific tenant. The service principal defines what the app can do inside that single workspace.
Teams choose between single-tenant and multi-tenant modes during the initial setup step. Single-tenant mode restricts logins to users and services within your own company directory. Multi-tenant mode allows accounts from external partner directories to log in as well. After picking a mode, admins create client secrets or upload public certificates. The tool uses these keys to prove its identity and request access tokens.
When a user or script logs in, the directory checks the assigned role. It then issues a signed token that lists the approved scopes and claims. The target service reads that token and trusts the caller for the whole session.
What native roles solve and what they miss
Native directory roles do a great job of proving who a user is. They let you force multi-factor checks and block logins from unknown devices. You can also put users into groups and assign them to specific tools. When someone leaves the team, disabling their profile cuts off their login right away.
Still, directory roles only check identity at the moment a session starts. Once the token is valid, the directory cannot see what happens next. It does not inspect the database queries, shell commands, or API calls in flight. A developer with a valid token can still run a bad delete query. They can also pull tables full of emails, phone numbers, or card numbers.
Microsoft Entra ID (Azure AD) + Per-App VPN: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Long-lived client secrets create another big problem for platform and security teams. Engineers often paste these secrets into local files, build scripts, or chat rooms. If an attacker steals that key, they gain every permission tied to the registration. Native directory logs show when a token was issued, not what data was read.
Keeping secrets and permissions tight in production
To reduce risk, teams should split registrations by service and by stage. Never share the same registration between your test tools and your production databases. Prefer short-lived certificates or workload identity federation over static client secrets whenever possible. Review assigned roles every quarter and drop any wide permissions that nobody uses.
Even with clean roles, identity checks alone cannot govern live queries or commands. Teams still need a way to inspect each action and rewrite sensitive fields.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between an app registration and an enterprise app?
The registration is the global template where you define settings, keys, and scopes. The enterprise app is the local service principal that controls user assignments and access.
Should I use client secrets or certificates for service logins?
Use certificates or federated workload identities whenever your tool supports them. Client secrets are just long passwords that are easy to leak in code.
Can an ms entra app restrict which SQL queries a user runs?
No, the directory only handles the login handshake and issues an identity token. It cannot read, approve, or mask individual database queries after the session starts.