SSO Domain
An sso domain links your company email domain to one central login service. You verify domain ownership with a DNS record and link your identity provider. Engineering teams use this setup to manage user accounts in one place. When a person joins the team, they get an email on that domain. That email grants them entry to cloud consoles, code hosts, and internal apps. Problems start when teams map broad permissions to everyone on the same domain. One login check often gives a user wide power acro
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An sso domain links your company email domain to one central login service. You verify domain ownership with a DNS record and link your identity provider.
Engineering teams use this setup to manage user accounts in one place. When a person joins the team, they get an email on that domain. That email grants them entry to cloud consoles, code hosts, and internal apps. Problems start when teams map broad permissions to everyone on the same domain. One login check often gives a user wide power across production systems.
How an sso domain works in your stack
Setting up an sso domain starts with your DNS provider and identity tool. First, you claim your company domain inside the target app or cloud platform. The platform gives you a unique text string to place in your DNS records. Your DNS server publishes this record so the platform can read it. Once the platform reads the record, it knows your team owns the domain.
Next, you link your identity provider to the platform using SAML or OIDC. You exchange metadata files, login URLs, and public keys between the two systems. You also map group names from your directory to roles in the target app. Now, when a user types their work email, the app checks the domain part. The app sees the claimed domain and sends the user to your identity provider.
The identity provider checks the user password and multi-factor token. After a good check, the provider sends a signed token back to the app. The app reads the group claims in the token and starts a user session. If you remove a person from your identity directory, their next login will fail. This setup saves time because admins do not make local accounts on each server.
What an sso domain solves and what it misses
A verified sso domain stops shadow IT and kills off weak local passwords. It makes sure every user passes through your multi-factor checks before they log in. It also helps security teams track which apps a user opened during the day. When an employee leaves the company, one click blocks their new login attempts.
Still, this login check only works at the front door of a session. Once a developer logs in to a database tool or cloud shell, the check ends. The identity provider does not see what queries or commands run inside that session. If a group role grants write permissions, the user can drop tables or read secrets. The login log only shows that the user entered the system at nine o'clock.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static group mappings also grow too wide over time as teams move fast. Admins often add a whole team group to a strong role to fix a ticket. Months later, dozens of people still hold high privileges they do not need daily. Also, shared service accounts and database tools often bypass the web login flow completely. Engineers still pass static keys around to run scripts or inspect live data.
Why runtime controls matter after login
To keep systems safe, teams must look past the initial domain login step. You need controls that inspect each command or query while the session runs. Instead of giving an engineer a broad role for a whole day, scope each action. When a user runs a safe read query, the system can allow it right away.
If that same user tries to run a risky change, a peer can approve it. Data masking can also rewrite sensitive fields like emails, phone numbers, or card numbers in results. This way, your identity provider still handles who the user is through their domain. Then, fine-grained runtime rules control what that user can do and read.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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
How do you verify an sso domain with DNS?
You copy a unique verification token from your app and add a DNS TXT record. Once your DNS host publishes the record, the app checks it and marks the domain active.
Can one identity provider manage more than one sso domain?
Yes, most identity providers let you add and verify multiple domains in one tenant. This helps when your company owns several brands or goes through a merger.
Does an sso domain control database queries after login?
No, domain login only checks user identity at the start of a session. It does not inspect SQL statements, shell commands, or API calls made after login.