SSO Certificates
You set up sso certificates by sharing a public key between your identity provider and target app. The identity provider signs each login assertion with its private key so the app trusts the user. Most teams set up this trust once and assign broad group roles to speed up work. When those roles are too wide, any signed user can run risky commands on backend systems. How sso certificates work during a login Single sign-on relies on digital signatures to prove who a user is. In a standard SAML w
SSH Certificates + Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up sso certificates by sharing a public key between your identity provider and target app. The identity provider signs each login assertion with its private key so the app trusts the user. Most teams set up this trust once and assign broad group roles to speed up work. When those roles are too wide, any signed user can run risky commands on backend systems.
How sso certificates work during a login
Single sign-on relies on digital signatures to prove who a user is. In a standard SAML workflow, the identity provider holds a private key. The target app stores the matching public certificate. When a team member logs in, the identity provider creates an assertion. This document holds the user email, group names, and a timestamp.
The identity provider signs this data with its private key before sending it. The target app reads the assertion and checks the signature with its stored public certificate. If the signature matches, the app knows the login data came from the trusted provider. It also knows nobody changed the role data in transit.
In OIDC setups, the identity provider publishes its public keys at a standard web address. The app fetches those keys to check JSON web tokens during login. Both methods rely on valid, unexpired keys to keep logins working across the team.
How to rotate keys without breaking logins
Every certificate has an expiration date. When a key expires, the target app rejects all new login attempts. Users get locked out of their tools right away. To prevent downtime, teams must rotate their keys before the old ones expire.
A safe rotation uses a dual-key overlap period. First, the admin creates a new key pair in the identity provider. Next, the admin uploads the new public certificate to the target app while keeping the old one active. Both systems now trust both certificates at the same time.
Once the app trusts the new certificate, the admin switches the active signing key in the identity provider. New logins now use the fresh key. After confirming that logins work, the admin removes the old certificate from both sides. This step finishes the rotation cleanly.
SSH Certificates + Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login trust solves and what it misses
Valid signing keys solve one specific problem. They prove that a login token came from your real identity provider. They stop attackers from forging login assertions to enter your apps. They also let you manage user accounts in one central place.
Still, certificate checks stop working the moment the login finishes. The certificate decides who gets into the system. It does not inspect what that person does during their session. Once an engineer opens a database session or server shell, the certificate plays no further part.
Many teams map an identity provider group to a shared database role or admin account. Everyone in that group gets the same broad rights after logging in. A valid login cannot stop a user from running a drop table query. It cannot block a script from pulling raw card numbers, phone numbers, or national IDs. Controlling live commands and masking sensitive fields requires controls that work inside the active session itself.
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
What happens when an SSO signing certificate expires?
The target app rejects all incoming login assertions signed by the expired key. Nobody can log in through single sign-on until an admin uploads and activates a new certificate.
What is the difference between an SSO certificate and an SSL certificate?
An SSL certificate encrypts web traffic between a browser and a server. An SSO certificate signs identity assertions so an app knows the login request came from your identity provider.
Can two apps share the same SSO signing certificate?
Yes, an identity provider can use one key pair for multiple apps, or generate unique keys per app. Using unique certificates per app limits the impact if you need to rotate a key early.