Pomerium vs OAuth2 Proxy: when each one fits
Choose Pomerium when you need per-route policies, attribute-based access, or non-HTTP reach such as SSH, TCP or UDP, or when you plan to front Kubernetes services through an ingress. Choose OAuth2 Proxy when you protect a small number of web apps, already run an OIDC provider, want identity passed to the app as HTTP headers, and your team is comfortable operating cookie or Redis sessions. Both sit in front of internal apps and both use OIDC for user identity, so the decision is about how much access logic lives in the proxy and what sits behind it.
Four questions settle most of it. First, how many applications and distinct access rules do you expect to maintain, and who will edit them? A handful of apps with one rule each rarely justifies a policy engine, while dozens of routes with different groups and device conditions do. Second, is any service non-HTTP? OAuth2 Proxy is an HTTP reverse proxy, so SSH, database or other TCP services need a different path. Third, how should sessions behave? OAuth2 Proxy's cookie sessions cannot be locked, so concurrent token refreshes can force a re-login, and Redis changes that trade-off and adds an component to run. Confirm how Pomerium manages sessions in the version you plan to deploy.
Fourth, is a hosted control plane acceptable? Pomerium Zero keeps application traffic in your environment while Pomerium hosts the control plane and management console, but Enterprise features such as directory sync, Rego policies and administrator RBAC sit in the Enterprise edition. Check the current Pomerium pricing page against your route and policy counts before you assume the free tier covers you. If your answer to the first two questions is simple and your control plane must stay fully self-hosted, a lightweight OIDC proxy with a documented session model is usually the faster path to a working deployment.
Pomerium vs OAuth2 Proxy by scenario
This table maps common internal access scenarios to the platform that fits each one better and the condition that decides it. Read each row against your own app inventory: the right choice depends less on team size than on whether you need per-route policy, non-HTTP access, or only a login gate in front of a few apps.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| One internal dashboard behind an OIDC provider | OAuth2 Proxy | A single web app with one login requirement and no per-route rules is the core use case for its lightweight OIDC reverse proxy model. Pomerium also works here, but its policy model adds configuration you may not need. |
| Dozens of apps with different access rules per group | Pomerium | Pomerium's policy-driven model is built for route-level rules such as attribute-based policies. Confirm which policy features your edition provides, since some advanced controls such as Rego policies are reserved for Enterprise. |
| SSH, TCP or database access alongside web apps | Pomerium | OAuth2 Proxy is an HTTP reverse proxy, so it does not cover SSH or database protocols. Pomerium's Zero plans list native SSH, TCP and UDP access through the CLI or desktop app, so confirm the exact feature set for your deployment. |
| Kubernetes services needing an ingress | Pomerium | Pomerium publishes a Kubernetes Ingress Controller under Apache-2.0. Choose it when you want the access proxy itself to act as the ingress. OAuth2 Proxy can also sit in front of Kubernetes services, so confirm the ingress pattern your cluster team already runs. |
| Existing app that only needs identity in HTTP headers | OAuth2 Proxy | OAuth2 Proxy forwards user, group and email headers such as X-Forwarded-User and can use the set-xauthrequest option with nginx auth_request. This is a close fit when the app already trusts headers and you do not need route-level policy. |
| Sessions must survive many concurrent users and token refreshes | Pomerium | OAuth2 Proxy's default cookie sessions cannot be locked, so concurrent refreshes can force re-login. If you choose OAuth2 Proxy, plan for Redis session storage. Confirm how Pomerium manages session state in your chosen architecture. |
| Illustrative: a small team wanting a fixed login gate for one admin tool | OAuth2 Proxy | A single admin tool, one identity provider and a small set of allowed users usually need little beyond the OIDC settings. The simpler configuration surface is the reason to pick it. |
| Illustrative: a regulated environment auditing who reached which route | Pomerium | Choose Pomerium when you need access and audit logs tied to policy decisions. Confirm which log and audit features are included in Core, Zero and Enterprise before you rely on them for evidence. |
How each proxy is built and what that means for operations
Both products put SSO in front of internal web apps, but they divide the work differently. Pomerium is a policy-driven access proxy with a Core edition you run yourself and an optional hosted control plane, while OAuth2 Proxy is a narrower authentication layer that sits in front of an app or beside an existing proxy. The choices below determine where state lives, what the reader must operate, and how failures show up.
Pomerium Core as a self-run cluster
Pomerium Core is Apache-2.0 software that you deploy and run in your own environment, and it includes the authorization policy engine that decides which users reach which routes. Because the cluster is yours, you own its upgrades, certificates, identity provider configuration and logging. Check which Core features your policy model needs, since directory sync, Rego policies and session management are reserved for the Enterprise edition.
Zero's hosted control plane
With Pomerium Zero, Pomerium hosts the control plane and management console, while the Core cluster runs in your environment so application traffic stays there. This splits the operational load: you still run the data path, but you do not run the management plane. Ask which configuration changes flow through the hosted control plane, how it is backed up, and what happens to routing if the connection to it is interrupted.
OAuth2 Proxy as a reverse proxy or middleware
OAuth2 Proxy can act as the reverse proxy in front of an app, or run as middleware next to an existing proxy such as nginx. In middleware mode, nginx sends each request to OAuth2 Proxy through auth_request, so the application keeps its own routing. Confirm which deployment pattern your ingress and existing proxies already support before choosing, because the two patterns create different failure points.
Session storage: cookies or Redis
By default, OAuth2 Proxy keeps sessions in encrypted cookies, which requires a cookie secret that every replica must share. Alternatively, it can store sessions in Redis, including Redis Sentinel or Redis Cluster, with only a ticket held in the cookie. Redis adds a service to run and secure, but it keeps the session state in one place. Decide which model fits your replica count and recovery plan before rollout.
Identity headers passed upstream
OAuth2 Proxy passes identity to applications in headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, and can forward the access token or ID token. In nginx auth_request mode, set-xauthrequest returns X-Auth-Request headers instead. Your applications must trust these headers only when they arrive through the proxy, so confirm that direct access to the upstream is blocked and that inbound copies of these headers are stripped.
Cookie sessions cannot be locked
With cookie sessions, OAuth2 Proxy holds no server-side state, but the session cannot be locked. When the browser sends several requests at once, concurrent token refreshes can conflict and force the user to sign in again. Test this with your own application and identity provider by generating parallel requests during a token refresh window. If the behavior is disruptive, Redis-backed sessions are the option to evaluate.
Pomerium vs OAuth2 Proxy feature by feature
This table sets Pomerium's policy-driven access proxy against OAuth2 Proxy's lightweight OIDC reverse proxy, row by row. Read each row against the workload you need to protect, and confirm any cell marked as needing verification in the vendor documentation before you commit.
| Capability | Pomerium | OAuth2 Proxy |
|---|---|---|
| License | Pomerium Core is Apache-2.0. Zero and Enterprise add paid, hosted or self-hosted control plane options. | Distributed under the MIT License, with no paid edition described in the supplied materials. |
| Latest release | v0.33.4, published October 2, 2026. | v7.15.5, published October 1, 2026. |
| Authorization policy model | Policy-driven access rules. Zero plans list attribute-based policies and continuous authorization. Rego policies are reserved for Enterprise. | Authenticates users and forwards identity to upstream apps. Confirm how far access rules can be expressed inside the proxy itself in its configuration overview. |
| Non-HTTP access | Zero plans list native SSH, TCP and UDP access through the Pomerium CLI or desktop app. Confirm which of these are included in your chosen plan. | Documented as a web reverse proxy for HTTP apps. Confirm its support for non-HTTP services in its documentation before relying on it. |
| Kubernetes ingress | Publishes an Apache-2.0 Kubernetes Ingress Controller in its own repository for running Pomerium as ingress. | Run as a proxy in front of services or as middleware alongside existing proxies, such as nginx auth_request mode. |
| Identity providers | Lists Apple, Auth0, Microsoft Entra ID, Cognito, GitHub, GitLab, Google, Keycloak, Okta, OneLogin and Ping. | Generic OIDC and OAuth2 providers, plus dedicated providers for Google, Microsoft Entra ID, GitHub and login.gov. |
| Session storage | Confirm session storage options and session management features in the Pomerium documentation, as session management is listed for Enterprise. | Encrypted client-side cookies by default, or Redis including Redis Sentinel and Redis Cluster. Cookie sessions cannot be locked, so concurrent token refreshes can force a new login. |
| Identity headers | Confirm which identity headers and claims are passed to upstream apps in the configuration you plan to use. | Passes X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email, and can pass the access token or ID token. |
| Governance status | Maintained by Pomerium, a commercial vendor that also sells Zero and Enterprise. | A Cloud Native Computing Foundation Sandbox project and a community-driven project. |
What is free, what is paid and what the license allows
Pomerium Core is the open-source edition, licensed under Apache-2.0 according to the pomerium/pomerium repository. Your team runs it inside your own environment, and the pricing page describes Core as open source and self-run. No vendor fee applies to Core itself, but your staff carries installation, upgrades, certificate handling, monitoring and incident response.
- License terms: Apache-2.0 allows use, modification and redistribution, including inside commercial products, subject to its notice and attribution conditions. Have counsel confirm the obligations that apply to your deployment.
- Kubernetes ingress: The Pomerium Ingress Controller is a separate project, also licensed under Apache-2.0, so you can run Core as the ingress for Kubernetes services without a paid tier.
- Release cadence: Pomerium v0.33.4 was published on October 2, 2026, after v0.33.3 on September 9, 2026 and v0.33.0 on July 16, 2026. Schedule upgrade windows around these releases and read each release note before moving.
- Who pays: Your organization pays for infrastructure, operations, staff time and any outside help. Licensing cost is zero, so the total cost depends mainly on how much operational work your team can absorb.
Before you commit to a version line, confirm the current release on the Pomerium GitHub releases page and check the license file in the repository.
Pomerium Zero adds a managed control plane and management console hosted by Pomerium, while the Pomerium Core cluster keeps running in your environment, so application traffic stays with you. The published plans are Zero Personal, free for personal use, and Zero Business, priced at $9 per user per month billed monthly or $7 per user per month billed annually. Check the Pomerium pricing page for the current terms before budgeting.
- Zero Personal: Free for personal use, with 1 cluster, 10 routes and 5 policies. It suits a single person testing the model, not a team deployment.
- Zero Business: Allows 5 clusters, 100 routes, 100 policies and 5 custom domains. Per-user fees recur monthly or annually, so headcount drives the bill upward.
- Included capabilities: Clientless web access, native SSH, TCP and UDP access, Kubernetes access, SSO, mTLS, attribute-based policies, continuous authorization, access and audit logs, a management API and Terraform support.
- Who pays what: The subscription pays for the hosted control plane and console. Your team still pays for running the data path, the certificates and the upstream identity provider.
For a team plan, confirm the per-user billing basis, the route and policy limits against your application count, and whether the Zero plan terms match your data residency requirements.
Pomerium Enterprise is priced by custom quote and uses a self-hosted control plane. According to the pricing page, it reserves directory sync, external data integrations such as FleetDM device posture, Rego policies, administrator RBAC, session management and SSH session recording and playback. Those features matter only if your access model needs them, so start from your requirements before reading the quote.
- Directory sync: Relevant when group membership in a corporate directory must drive access policy automatically. If your groups change often, ask how each edition handles group data without this feature.
- Device posture: The FleetDM integration is the named example. It matters when access decisions depend on the state of the endpoint, such as whether a device is managed and current.
- Rego policies and administrator RBAC: Relevant for teams that want policy written as code and separate roles for people who administer the proxy.
- Session management and SSH recording: Relevant where privileged SSH sessions must be recorded and replayed for audit. Confirm retention and storage responsibilities with the vendor.
- Quote components: A custom quote should list licensed features, support terms, the control plane hosting model and any recurring fees. Ask for these in writing, because the published tiers do not show their values.
Request a written feature list from the vendor and map each reserved feature to a control or audit requirement in your own environment.
OAuth2 Proxy is distributed under the MIT License and describes itself as a community-driven Cloud Native Computing Foundation Sandbox project. The supplied facts name no paid edition, subscription or commercial tier, so do not assume that one exists. Confirm with the maintainers or any vendor you are considering whether commercial support is available and what it covers. Without it, the cost is staff time, infrastructure and any support you buy from a third party.
- License terms: The MIT License is permissive and requires preservation of its copyright and license notice. Have counsel confirm the obligations for your products and internal tools.
- Release line: OAuth2 Proxy v7.15.5 was published on October 1, 2026, after v7.15.4 in August and v7.15.3 in June. Track the OAuth2 Proxy releases page when you plan upgrades.
- Session storage cost: Encrypted cookie sessions need a cookie secret and no extra service. Redis-backed sessions add a Redis deployment, including Sentinel or Cluster options, that your team must run, secure and back up.
- Who pays: Your organization pays for infrastructure, operations and internal engineering time. Licensing cost is zero under the supplied facts.
Before purchase, re-check the license file and the release history, and get any support terms in writing from the party that provides them.
How the cost of ownership differs between the two
Cost of ownership for these two tools is mostly a question of staff time, not licence fees. Both Pomerium Core and OAuth2 Proxy are open source with no licence charge (Apache-2.0 and MIT respectively), so the recurring spend falls into four buckets: infrastructure to run the proxy, the people who write and maintain access rules, the identity provider, and any support contract. The identity provider is licensed separately and applies to both options, so it does not change the comparison. OAuth2 Proxy adds a Redis cost only if you choose Redis sessions over encrypted cookies, and Pomerium adds a hosted control plane fee only if you pick Pomerium Zero (Business at $9 per user per month billed monthly or $7 billed annually, per Pomerium's pricing page) or Enterprise, which is priced on request. Ask whether your quote includes the Pomerium Core cluster you run yourself, since that compute sits on your bill either way.
One-time work is front-loaded in both cases. For Pomerium, that means designing the policy model, wiring identity providers, and setting up the Kubernetes Ingress Controller if you use it. For OAuth2 Proxy, the work is mostly one deployment per application or a shared proxy in front of nginx auth_request, plus session storage decisions. Migration from an existing VPN or header-based setup is a one-time cost in either case. Recurring work includes policy changes as applications and groups change, upgrades (the current OAuth2 Proxy line is v7.15.5 and Pomerium is v0.33.4, so track both release streams), and rotation of certificates, client secrets and provider configuration. Policy volume is the main driver: Zero Personal allows 10 routes and 5 policies, while Zero Business allows 100 routes and 100 policies, so a larger estate may push you onto a higher tier. Non-HTTP coverage for SSH, TCP or UDP is available in Pomerium Zero but is outside what OAuth2 Proxy is built to do, so it can add a second tool and a second set of costs.
When requesting a quote, specify the number of applications, routes, policies, identity providers, and whether non-HTTP services need coverage. Ask whether session storage will be cookie-based or Redis, and who operates Redis and the Kubernetes ingress. Confirm which Pomerium features you need, because directory sync, Rego policies, RBAC for administrators and session management are reserved for Enterprise, and that changes the licence line entirely. Request the support scope, response expectations and upgrade cadence in writing. DeployOpen does not publish prices. Quotes follow from a written scope that defines the systems, deliverables and timelines, so the more precisely you describe your estate, the more useful the quote will be.
Moving from OAuth2 Proxy to Pomerium, or back
This sequence moves internal web apps from OAuth2 Proxy to Pomerium one group at a time, so each app keeps working while its identity headers, policies and session handling are rebuilt and checked. The same steps, read in reverse, cover a move back to OAuth2 Proxy.
Inventory apps and their proxy dependencies
The platform or security team lists every app behind OAuth2 Proxy, including hostnames, whether OAuth2 Proxy runs as a reverse proxy or as middleware (for example, nginx auth_request), and which headers each upstream reads, such as X-Forwarded-User, X-Forwarded-Groups, X-Forwarded-Email or the forwarded access or ID token. Record the session store in use, either encrypted cookies or Redis, and any app that relies on token refresh behavior. The inventory is done when every app has an owner, a header list and a session note, and the owners have signed off on it.
Map upstream header needs to Pomerium policy
For each app, the team compares the header contract in the inventory with what Pomerium provides through its identity provider integration and its route and policy configuration. Pomerium uses OAuth 2.0 and OIDC for user identity, and the identity provider registration can usually stay in place, but each upstream's header names and group-based access rules must be written down as routes and policies. Confirm the exact claim and header behavior for your Pomerium version in its documentation before any app is changed. The mapping is done when each app has a written header and policy specification that the upstream owner has reviewed.
Stand up Pomerium beside the existing proxy
The platform team deploys Pomerium Core in the same environment as the current proxy, using the identity provider registration that already serves the existing apps, and points a non-production hostname at one low-risk upstream. Kubernetes teams can use the Pomerium ingress controller for that route, while others configure Pomerium directly. Testers sign in through the new route and check the headers the upstream receives against the mapping from the previous step. The step is complete when the test route passes the header checks and sign-in, logout and session expiry all behave as documented for the chosen session setup.
Migrate policies group by group
Migration proceeds one group of apps at a time, starting with the group that has the fewest dependencies. For each app, the team rebuilds the routes and policies from the mapping, keeps group names unchanged so existing directory memberships still apply, and runs a side-by-side access test with a set of accounts from each group. The owning team confirms that users who should have access have it and that users who should not, do not. Each group is finished when its access test results are recorded and the owners approve the cutover.
Cut over DNS or ingress per app
For each app, the platform team changes DNS or the ingress resource so the public hostname resolves to Pomerium rather than OAuth2 Proxy, and keeps the previous configuration ready to restore. Users with active sessions are told they may need to sign in again, because session state does not carry over between the two proxies. The team watches sign-in errors and upstream logs for the agreed period, then removes the old route. The cutover is complete when the hostname serves through Pomerium, the old route is disabled, and no authorization errors remain in the logs.
Retire OAuth2 Proxy and its session store
When every app has moved, the team removes OAuth2 Proxy deployments, their configuration files and cookie secrets, and any Redis instance that held OAuth2 Proxy sessions, after confirming that nothing else reads from it. Stored client secrets and the cookie secret are rotated or deleted according to the organization's key management practice. The team updates the architecture diagram, the access review inventory and the runbooks. The step is done when no OAuth2 Proxy process, route or session store is still running and the documentation reflects the new setup.
Reverse the sequence to return to OAuth2 Proxy
A move back follows the same steps in the same order, with the header and policy mapping written in the other direction. Upstreams that read X-Auth-Request or forwarded headers may need their expected names confirmed against OAuth2 Proxy's set-xauthrequest and header options, and any per-route policy detail that Pomerium expressed as routes and policies must be restated as OAuth2 Proxy configuration, which offers less per-route control. Teams should expect to lose some of that detail and should record it before cutover. The reverse move is complete when the access test for each group matches the policy record that was agreed before the change.
Confirm what transfers and what is rebuilt
Before any cutover, the team records what carries over and what must be built again. The identity provider registration, group names, directory memberships and upstream application code generally transfer, because the apps and directory stay in place. Routes, policies, header configuration and session configuration are rebuilt for the new proxy, and active sessions do not move. The owners sign this list before the first group is migrated, and the list is kept with the runbook so a later move can start from the same record.
What implementing each one involves and where projects run long
Both options start with the same identity provider work: registering a client with your IdP (Keycloak, Microsoft Entra ID, Okta and so on), setting the redirect URIs to the exact callback path each proxy uses, and deciding which hostnames and TLS certificates front each app. For OAuth2 Proxy, the team then sizes session storage: a cookie secret for encrypted client-side sessions, or a Redis deployment (including Sentinel or Cluster mode) if sessions must live server-side. For Pomerium, the main work is policy design: writing routes and the attribute-based policies that decide who reaches which app, then testing them against a staging set of users and groups before cutover. Confirm the current configuration keys and route syntax against the Pomerium docs and the OAuth2 Proxy configuration overview rather than relying on older examples.
Kubernetes ingress is where the two diverge most in effort. Pomerium offers an Apache-2.0 ingress controller in its own repository, so the team configures ingress resources and Pomerium routes together. OAuth2 Proxy is commonly placed as a sidecar or in front of an ingress controller, with an auth_request pattern on nginx. Either way, each upstream app needs a change: it must trust the identity headers only when they arrive from the proxy. For OAuth2 Proxy that means X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email. Apps that accept these headers from any caller, without checking that the request came through the proxy, are a common source of spoofing risk, so plan network restrictions and header validation as part of the scope.
Projects usually run long for four reasons. First, group ownership is unclear: nobody can say who maintains the IdP groups that policies depend on, so access decisions stall. Second, header trust is assumed rather than tested. Third, non-HTTP services such as SSH, databases or TCP tools are discovered late, which matters more for Pomerium, where those routes are part of the design, than for OAuth2 Proxy, which handles web traffic. Fourth, cookie and token refresh issues appear under load: OAuth2 Proxy's cookie sessions cannot be locked, so concurrent refreshes can force logins, and policy sprawl builds up as every team adds exceptions. Ask any implementer to inventory apps, protocols, groups and refresh behavior before estimating. DeployOpen delivers implementation as fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as a retainer.
Questions buyers ask before choosing Pomerium or OAuth2 Proxy
What does the work need from our own team before we pick Pomerium or OAuth2 Proxy?
Both options need someone who owns the identity provider configuration, the DNS and TLS for each protected host, and the upstream applications' trust of identity headers or tokens. OAuth2 Proxy asks for the most hands-on setup of the reverse proxy itself, with its own configuration file, cookie secret or Redis session store, and an upstream reverse proxy or ingress that you already run. Pomerium moves more of the access rules into policy, so the people who write those policies need to understand your user groups, device posture needs and routes. Before you commit, list which apps need protection, which identity provider you use, and who will be on call for the proxy. Those answers decide the skills you need more than the product choice does.
Can a small team run either option without outside help?
A small team can run OAuth2 Proxy in front of a handful of apps if it already operates a reverse proxy, a TLS certificate process and an OIDC provider such as Keycloak or Microsoft Entra ID. The configuration is narrow, and the project documents each option. Pomerium also suits a small team, and its Zero plans move the control plane to a managed service while your cluster still runs in your environment. The harder question is ownership after go-live: upgrades, cookie or session incidents, policy reviews and audit log handling. If nobody on the team has time for those tasks every month, a retainer or a fixed-scope implementation partner can cover them, but that is a budget decision you should make in writing.
How long does a migration take, and what sets that timeline?
No supplied fact gives a migration duration for either product, so treat any figure you hear, including ours, as a claim to check against a written scope. The timeline depends on the number of applications, whether each one already trusts identity headers or must be changed, how many identity providers and groups you map, whether sessions need to survive cutover, and how many non-HTTP services you intend to move. OAuth2 Proxy migrations often turn on the session storage choice and the header contract with each upstream app. Pomerium migrations often turn on writing and testing policies for each route. Ask any implementer to break the timeline into discovery, a pilot app, a staged rollout and a rollback plan.
Does Pomerium Zero keep our application traffic inside our environment?
Yes. According to Pomerium's pricing page, with Pomerium Zero you run the Pomerium Core cluster in your own environment, while Pomerium hosts the control plane and management console. Application traffic therefore stays in your environment. The control plane is the managed part, so ask Pomerium what data the hosted control plane stores, how it is administered and where it is hosted before you send any policy or identity data to it. Your security and compliance teams should review that data flow against their own requirements. Zero Business and Zero Personal also carry route and policy limits, which are listed on the pricing page and should be checked against your planned footprint.
Can OAuth2 Proxy protect SSH or raw TCP services?
OAuth2 Proxy is documented as an authentication reverse proxy for HTTP applications, with identity forwarded to upstream apps as headers. Its supplied documentation does not describe SSH or raw TCP access, so do not assume it covers those protocols. Confirm the current scope in the project documentation and test with your own services before you plan around it. Pomerium lists native SSH, TCP and UDP access through its CLI or desktop app in its Zero plans, and reserves SSH session recording and playback for its Enterprise edition. If non-HTTP access is a requirement, put it in the written scope and validate it in a pilot.
What does a consultant or implementation partner add to either option?
An implementation partner plans the rollout, configures the identity provider and proxy, writes or reviews policies and headers, tests the protected apps, hardens the deployment, documents it and hands over runbooks. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers. Ask for a written quote tied to a defined scope, not a generic package.
What should we ask for in a written scope?
Ask for a scope that lists every protected application, its protocol and the identity claims it needs, the identity provider integration and its owner, the session storage design and failure behavior, the Kubernetes or ingress layout if one applies, and the test cases that prove each route. Request explicit exclusions, such as protocols or apps not covered. Require a rollback plan, a handover of configuration and runbooks, and a list of what is one-time versus recurring, including upgrades and any retainer. Confirm which vendor licenses are included and which are your responsibility, including any Pomerium Zero or Enterprise subscription. Finally, ask for acceptance criteria written in terms your team can test.
How DeployOpen helps choose and implement an SSO proxy
DeployOpen helps teams decide whether a policy-driven access proxy or a lighter OIDC reverse proxy fits their internal web apps, then implements the choice inside the client's own infrastructure. The work starts with a written scope that names the applications, identity provider, routing and session requirements before any configuration begins.
How we scope
- We inventory the internal apps, their protocols and which need non-HTTP access such as SSH or TCP.
- We record the identity provider, group claims and the authorization rules each application needs.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We deploy the chosen proxy in your cloud account, data center or air-gapped network.
- We configure session storage, cookie or Redis, and test how token refresh behaves under real login patterns.
- We test authorization policies, header forwarding and Kubernetes ingress routes against the agreed scope.
How we hand over
- We document the architecture, configuration, policy definitions and the reasons behind each design decision.
- We provide runbooks for adding applications, rotating cookie secrets and upgrading the proxy version.
- We walk your operations and security staff through the system so they can run it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can prepare access control and logging evidence for your compliance assessors, who issue any audit opinion.
- Confirm the exact support windows and license terms for the version you choose with the project or vendor.
