Single Signon Protocols
Single signon protocols let one user log in to many tools with one password. Teams set up these rules to link their central user list with internal systems. Most teams pick SAML or OIDC to verify who a person is at login. This setup stops password reuse across the company. Yet broad user roles still give people too much power after they log in. How single signon protocols work in practice A login system has two main parts that talk to each other. The identity provider holds the master list of
Emergency Access Protocols + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Single signon protocols let one user log in to many tools with one password. Teams set up these rules to link their central user list with internal systems. Most teams pick SAML or OIDC to verify who a person is at login. This setup stops password reuse across the company. Yet broad user roles still give people too much power after they log in.
How single signon protocols work in practice
A login system has two main parts that talk to each other. The identity provider holds the master list of users, passwords, and group names. The service provider is the database, cloud console, or app the user wants. When a user tries to log in, the app asks the identity provider for proof. The user types their password and passes a second check on their phone. Then the identity provider sends a signed message back to the app. Both sides share public and private keys ahead of time to check this signature. The message contains the user email and group names. The app reads the group names and maps the user to a local role.
Choosing between SAML, OIDC, and Kerberos
Teams choose between three main login standards based on their tech stack. SAML uses signed XML messages and works well for older web apps and cloud consoles. It passes rich group data during browser redirects. OIDC builds on OAuth and uses light JSON tokens instead of big XML files. Modern web apps, mobile tools, and command line tools favor OIDC for fast checks. Kerberos works best for older internal servers and local domain machines. It uses encrypted tickets over the local network instead of browser redirects. Most modern teams run SAML and OIDC side by side in the same provider. They pick the right standard for each tool they connect.
What login checks solve and what they leave open
Central login rules solve the first step of security very well. When someone leaves the team, admins turn off one account to stop all logins. Multi-factor checks also block stolen passwords at the front door. Still, login protocols only verify who a person is when the session starts. Once the app grants a local role, the login provider leaves the picture. A developer mapped to a shared database role can run any query that role allows. The login system does not see which tables they read or change. It cannot block a bad drop statement or rewrite emails and card numbers in results. Teams still need controls that inspect and log actual commands during the session.
Emergency Access Protocols + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
What is the main difference between SAML and OIDC?
SAML sends user data in XML format and relies on browser redirects. OIDC sends JSON tokens and works well with APIs, mobile apps, and command lines.
Do single signon protocols control what users do inside a database?
No, login protocols only verify identity and pass group names at the start. The target system controls what commands or queries the user can run after login.
How do group claims map to local permissions?
The identity provider sends a list of group names inside the signed login token. The target tool reads that list and assigns a matching local role for the session.