Entra Id Discovery Url
You find the entra id discovery url inside your cloud directory portal under endpoints. This address gives your apps the public keys and login links needed for single sign-on. Teams use this link to set up OpenID Connect for internal tools and databases. When teams assign broad directory roles during setup, users often gain too much reach. How the entra id discovery url works in practice Modern apps need a standard way to check user identities at login time. OpenID Connect solves this by publ
Microsoft Entra ID (Azure AD) + AI-Assisted Vulnerability Discovery: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You find the entra id discovery url inside your cloud directory portal under endpoints. This address gives your apps the public keys and login links needed for single sign-on. Teams use this link to set up OpenID Connect for internal tools and databases. When teams assign broad directory roles during setup, users often gain too much reach.
How the entra id discovery url works in practice
Modern apps need a standard way to check user identities at login time. OpenID Connect solves this by publishing a single metadata document at a known web address. When you set up an app, you paste the entra id discovery url into its settings. The app reads this web address to find where to send users to log in.
The metadata document also lists the public keys that sign security tokens. Your app fetches these keys to check that incoming login tokens are real. It also learns which user claims and directory scopes the identity provider supports. Because the app reads this data on its own, key rotation happens without manual updates.
Each cloud tenant has a unique identifier built into its discovery address. You can use a tenant-specific link to allow only your own staff to log in. You can also use a general link if you build apps for multiple companies. Most internal platform teams pick the tenant-specific link to keep login boundaries tight.
Managing directory groups and token claims
After you link the discovery endpoint, you must decide what data goes into the token. Directory admins map user groups and job roles into token claims. When a user logs in, the app reads those claims to grant local permissions. This step connects your central directory to your databases, cloud consoles, and internal servers.
Problems start when teams create coarse groups to speed up this mapping work. A single engineering group might grant full admin rights across fifty different backend systems. Adding a new developer to that group gives them write permissions everywhere at once. Reviewing these group assignments takes hours because the token claims do not show actual usage.
Teams also struggle when emergency fixes require temporary rights for an on-call engineer. Admins often add the user to a high-privilege group and forget to remove them later. Over time, this habit leaves dozens of staff members with permanent admin tokens. The discovery link keeps the login step clean, but group sprawl creates real risk.
Microsoft Entra ID (Azure AD) + AI-Assisted Vulnerability Discovery: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and where it stops
Using the entra id discovery url centralizes how people log into your systems. It removes the need to store local passwords inside every database and server. When someone leaves the company, you disable their main account in one place. That single action blocks them from getting new tokens across every linked app.
Still, the identity provider only checks who a person is at the login screen. Once the app checks the token and starts a session, the directory steps back. The login flow cannot see what queries or commands a user runs inside the session. It treats a safe read query the same as a command that drops a table.
Directory logs also lack details about what data left the system during a session. You can see that an engineer logged in at nine in the morning. You cannot see if their query returned raw emails, phone numbers, or card numbers. Controlling live sessions requires controls that inspect every request and rewrite sensitive fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Where do I find the discovery endpoint in the portal?
Open your app registration overview page and select the endpoints panel at the top. Look for the OpenID Connect metadata document link and copy that web address.
Why does my app fail to read the metadata link?
Check that your server has outbound network reach to the public cloud login domain. Also verify that you pasted the full metadata link with the tenant identifier included.
Does the discovery document expose private tenant secrets?
No, the metadata document only contains public signing keys and standard login URLs. It is safe for public clients to read and never exposes private keys or passwords.