Hoppscotch OIDC
You set up hoppscotch oidc by linking your identity provider to your self-hosted instance. This link lets your team log in with single sign-on credentials. Most engineering teams pair their identity tool with the API client to manage users. They map existing directory groups to workspaces so developers can share collections. Still, broad workspace roles often give users full rights to live API keys. One developer can run a bad request that deletes real user records. How the hoppscotch oidc log
K8s OIDC Authentication: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up hoppscotch oidc by linking your identity provider to your self-hosted instance. This link lets your team log in with single sign-on credentials. Most engineering teams pair their identity tool with the API client to manage users. They map existing directory groups to workspaces so developers can share collections. Still, broad workspace roles often give users full rights to live API keys. One developer can run a bad request that deletes real user records.
How the hoppscotch oidc login flow works
The hoppscotch oidc flow starts when a user clicks the login button. The app sends the user to your identity provider to check their identity. The user enters their work email, password, and second factor code there. Once the provider checks the user, it sends a signed token back. The API client reads this token to find the user email and profile. It then creates a local account or matches an existing user record. You configure this link by creating a client app in your identity tool. The identity tool gives you a client ID, a secret, and URLs. You add these values to your self-hosted setup and set the callback URL. When the service restarts, your team can log in with their work accounts.
Why team workspaces still share raw API secrets
After a user logs in, they join a shared team workspace. Team workspaces store API request collections and shared variables for the whole group. These variables often hold bearer tokens, basic auth keys, and service passwords. Any member who can read the workspace can also read these shared keys. Developers need these keys to send test requests to staging and production APIs. Because the client runs requests in the browser or on a desktop, keys travel to the user machine. A user can copy a shared token from the variable list at any time. If an account gets compromised, an attacker can pull every key in that workspace. The login check only guards the front door of the app itself.
What native login checks miss during API calls
Single sign-on proves who opened the API client at the start of the day. It allows admins to turn off accounts when someone leaves the company. It also removes the need for separate passwords on your testing tool. Yet the native login setup stops working once the workspace loads on screen. It does not check what individual HTTP requests do while in flight. A logged-in user can still send a delete call to a live endpoint. They can also fetch responses that hold sensitive customer emails or card numbers. The identity provider never sees the API payload or the returned data. To control what happens during API calls, teams need controls on the request path. Data masking can rewrite matched fields like phone numbers or national IDs in results. Request checks can also require a peer review before a write call runs.
K8s OIDC Authentication: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does hoppscotch oidc work on the cloud version or self-hosted?
Custom identity provider links are built for self-hosted instances that your team runs. You set the provider keys in your own server settings to enable login.
Does OIDC login stop developers from seeing shared workspace tokens?
No, logging in with single sign-on only controls who can open the workspace. Once inside, members can still read the variables and keys shared with their role.
How can teams protect customer data in API responses?
Login tools cannot filter the data that an API sends back to a user. Teams use response masking to rewrite emails, card numbers, and phone numbers in results.