Postman Single Sign on
You set up postman single sign on by linking your identity provider to your team account. Once you trade trust metadata, users log in with their work email and corporate credentials. Teams often map broad company groups to shared workspaces during this first setup step. That fast choice can give every engineer edit rights over production API keys and test scripts. How postman single sign on works Your identity provider holds the source of truth for user accounts and group names. When you turn
Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up postman single sign on by linking your identity provider to your team account. Once you trade trust metadata, users log in with their work email and corporate credentials. Teams often map broad company groups to shared workspaces during this first setup step. That fast choice can give every engineer edit rights over production API keys and test scripts.
How postman single sign on works
Your identity provider holds the source of truth for user accounts and group names. When you turn on single sign on, the API client trusts signed assertions from that provider. A user clicks the login button and moves to your corporate login screen. The provider checks their password and second factor before sending a signed token back.
The platform reads that token to match the user with a workspace member record. If it is their first visit, automatic provisioning can create a fresh seat right away. Group attributes in the login token can also assign the user to specific team roles. When an admin removes someone from the central directory, their next login check fails.
Teams should test the login flow with an admin account still open in another browser. You must also claim and verify your company email domain to enforce single sign on. Without domain enforcement, users might still log in with old passwords and bypass your provider.
Choosing roles and workspace permissions
Logging in is only the first gate for a developer working with shared API collections. Inside the tool, admins assign roles at the team, workspace, collection, and variable levels. A billing role manages invoices, while an editor role changes shared request URLs and headers. Viewers can run saved calls on their laptops, yet they cannot alter the team copy.
Many teams map every developer into a single workspace editor group to save time. That shortcut lets anyone read shared secret tokens stored inside team variable lists. A better approach splits workspaces by stage, keeping local test collections far from live systems. You should map directory groups so only approved leads can edit shared variables.
Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What login checks solve and what they leave open
Central login stops former workers from opening the app and reading saved workspace collections. It enforces multi-factor rules and password rotation policies from one single directory screen. Auditors can check the identity provider log to see who entered the workspace today.
Still, single sign on only checks who opens the client app at the start. It does not watch or filter the actual HTTP calls that leave the user desktop. Once logged in, an engineer still holds raw API keys or database strings in variables. Those static credentials can run destructive delete calls or pull full tables of customer records.
A login token also cannot mask sensitive fields returned inside a large JSON payload. If a response holds emails, phone numbers, card numbers, or national IDs, the payload shows all of them. Masking tools must sit in the request path to rewrite matched fields in results. Securing the workspace login is vital, yet teams still need controls over live requests.
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
What happens to existing accounts when we turn on single sign on?
Existing users with matching company emails link their old accounts during their next login. Their saved collections and personal workspaces stay intact after they confirm the account link.
Can external contractors still join a workspace without a company email?
Yes, admins can allow guest logins or add contractors to a separate identity group. You can scope those external accounts to a single workspace with viewer rights only.
Does single sign on protect API keys stored inside shared variables?
No, single sign on only gates who can sign in to the workspace app. Any member with read rights to a variable can still copy the raw key value.