Postman SSO
You set up postman sso by linking your identity provider through SAML or OIDC. This setup lets your team log in with their main work accounts. Teams often assign broad workspace roles so engineers can share API collections fast. Broad roles let too many users read and send live production keys. How postman sso works with your identity provider First, an admin opens the team settings and starts a new login method. You pick your identity provider and choose a standard protocol like SAML. The pl
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up postman sso by linking your identity provider through SAML or OIDC. This setup lets your team log in with their main work accounts. Teams often assign broad workspace roles so engineers can share API collections fast. Broad roles let too many users read and send live production keys.
How postman sso works with your identity provider
First, an admin opens the team settings and starts a new login method. You pick your identity provider and choose a standard protocol like SAML. The platform gives you unique service URLs to paste into your identity app. Your identity app then returns an XML metadata file or a login URL.
Next, you map user attributes like email and name between both systems. You can also turn on automatic user provisioning using the SCIM standard. SCIM creates accounts when staff join and removes them when staff leave. Once you test the link, you require all team members to log in this way.
After login, the app assigns each person a base role in the workspace. These roles control who can edit collections, variables, and shared test scripts. Admins can also map identity groups to specific team roles during login. This step keeps workspace permissions in sync with your main user directory.
What native login controls solve and what they miss
Single sign-on solves account sprawl and stops ex-employees from opening your team workspaces. Centralizing login ensures every user passes multi-factor checks before seeing shared API docs. SCIM provisioning also saves hours of manual work when teams grow or change. Security teams get a clear log of who opened the app and when.
Still, app login only checks who opens the workspace, not what requests run. Engineers still paste raw bearer tokens and database keys into shared workspace variables. Anyone with read rights in that workspace can copy those live keys out. When a user hits send, the request goes straight to your production API.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The native login check cannot inspect the payload or block a bad delete call. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers. If a response holds national IDs, that data lands right on the laptop. You need controls that check every live request, not just the morning login.
How to protect shared keys and production API calls
Start by removing raw production keys from shared team collections and cloud workspaces. Keep local variables on user machines instead of syncing them to the cloud. Split your workspaces by risk level so fewer people touch production settings. Give most developers viewer roles on core collections and limit who can edit.
Review your identity group mappings every quarter to catch role creep early. Turn off public link sharing so internal API paths stay inside your company. Check your audit logs often to spot unusual exports or role changes. Pair your login setup with runtime checks that govern every live API call.
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
Does single sign-on hide API keys stored in shared workspaces?
No, single sign-on only checks who can log into the main team app. Once inside, users can still view shared variables unless workspace roles block them.
What happens to active sessions when we remove a user in our identity app?
If you use SCIM, the system deactivates the user account right away. Without SCIM, the user stays active until their current session token expires.
Can we force all team members to use single sign-on only?
Yes, admins can turn off password logins once the identity link works. Team Admins usually keep a backup login link in case the provider fails.