Open-source alternative to PingAccess: the short answer
If your PingAccess renewal, a Ping licensing change or the need to keep web apps and APIs behind one login has put you in front of a decision, the short answer is that Pomerium or authentik's proxy provider, placed in front of a self-hosted identity provider, can cover most PingAccess use cases. Header-based applications and legacy apps will need the most testing, because they depend on how identity is passed upstream and on routing behavior that differs from PingAccess. Pomerium Core is licensed under Apache-2.0 and is self-run, so the gateway itself carries no license fee. The proxy provider in authentik's free edition is available under the MIT-licensed core, though support in that edition is community-only.
Both vendors reserve some enterprise policy features for paid tiers. On the Pomerium side, Rego policies, RBAC for administrators, session management and directory sync sit in the Enterprise edition, and Zero plans add a managed control plane with the cluster still running in your environment. On the authentik side, the enterprise directory is under a separate EE license and features such as privileged access management and ticket-based support are paid. Before you compare prices, list which of your current PingAccess policies depend on those features, and confirm the current terms directly with each vendor, since editions and limits change.
Start by exporting your PingAccess site, application and policy definitions, then sort each protected app into a simple header-based group, an OIDC-capable group and a legacy group that needs custom handling. That inventory tells you whether a proxy pattern fits and where your test effort will go. Do not assume that a proxy that works for modern web apps will also serve your header-trusting or non-browser API clients without a pilot.
How PingAccess capabilities map to open-source options
This table maps core PingAccess functions to Pomerium, the authentik proxy provider and Keycloak as the identity source. Each cell marks a capability as covered, partial or to be confirmed, and notes where it sits in a paid edition or needs another component. Read the Keycloak column as the identity layer behind a proxy, since Keycloak does not sit in front of applications on its own.
| Function | Pomerium | authentik proxy provider | Keycloak as identity source |
|---|---|---|---|
| Reverse proxy for web apps | Covered: identity-aware reverse proxy for internal web apps, Apache-2.0 Core, self-run. | Partial: proxy provider works through the embedded outpost; confirm fit for each app type. | Not applicable: Keycloak authenticates users but does not proxy app traffic. Pair it with a proxy. |
| SSO to applications | Covered: OAuth 2.0 and OIDC, with Keycloak, Okta, Entra ID and others as upstream providers. | Covered: proxy authentication is included in the free edition, with community support only. | Covered: OIDC, OAuth 2.0 and SAML 2.0 single sign-on for applications and the proxy client. |
| Policy rules | Partial: attribute-based policies included; Rego policies and administrator RBAC are Enterprise-only. | Partial: policy and group bindings in the free edition; confirm per-route granularity for your apps. | Partial: roles, groups and fine-grained authorization services; route rules still live in the proxy. |
| Header injection to apps | To be confirmed: check the header pass-through and set options in Core for your app's header contract. | To be confirmed: confirm which user and group headers the proxy sends to each application. | Partial: protocol mappers define the claims that the proxy turns into headers. |
| Token mediation for APIs | To be confirmed: confirm whether your version forwards or exchanges tokens for API routes. | To be confirmed: proxy mode is aimed at web apps; test token forwarding for APIs before relying on it. | Covered for issuing OAuth 2.0 tokens; confirm the grant types and token exchange your APIs need. |
| Session handling | Partial: session management is Enterprise-only; confirm the Core session behavior you need. | To be confirmed: session lifetime and forced logout per application in your edition. | Covered: realm-level SSO session settings; confirm per-client timeouts for each application. |
| Logging and audit | Partial: access and audit logs in Zero plans; SSH session recording is Enterprise-only. | Partial: event logging in the free edition; enhanced audit logging requires Enterprise. | Covered: login and admin events with metrics documented; confirm retention and SIEM export. |
Choosing between Pomerium and authentik's proxy provider
Both options put an identity-aware layer in front of internal web apps and APIs that have no login of their own, which is the job PingAccess does today. The right choice depends less on features than on whether you want a dedicated gateway or an identity provider that already handles the proxy role.
Pomerium Core as a dedicated gateway
Pomerium Core is Apache-2.0 licensed and self-run, so you can deploy the proxy without a subscription. It fits teams that want a gateway separate from the identity provider, with Kubernetes ingress support through the separately licensed Apache-2.0 ingress controller. Check which identity provider you will federate with, since Pomerium lists Keycloak, Okta, Microsoft Entra ID and Ping among supported providers, and confirm how your team will manage policy files at scale.
Pomerium Enterprise feature boundary
Rego policies, directory sync, RBAC for administrators and session management are Enterprise features, not part of Core. If your PingAccess policies depend on Rego-based rules or on directory-driven group membership, budget for an Enterprise conversation before cutover. Ask Pomerium to confirm which of your current rules can be expressed with the attribute-based policies available in Core and which would need the Enterprise edition.
authentik proxy provider for existing deployments
If authentik already issues your logins, its proxy provider adds protected applications without a second product. The proxy outpost sits in front of applications and enforces authentication through the same policies and users. This is the simpler path for teams that have already chosen authentik for SSO. Confirm that your application's header-based identity model maps to the headers the proxy sends.
authentik edition boundaries
The open-source core is MIT licensed, while the enterprise directory falls under a separate EE license. The free edition includes proxy authentication but offers community support only. Enterprise adds ticket-based support and integrations such as Microsoft Entra ID, and Enterprise Plus adds SLAs. If your cutover needs a contractual support path, confirm which edition covers that before you commit to the proxy design.
Coupling risk with the identity provider
Using authentik as both identity provider and access proxy concentrates failure in one system. If authentik is down or misconfigured, sign-in to every protected app stops at once. A dedicated gateway keeps the access layer separate, but adds a second component to patch and monitor. Test how each design behaves during an identity provider outage and document the fallback before choosing.
Versioning and upgrade cadence
authentik releases are named by year and month, and its security policy lists supported release lines that receive fixes. Pomerium publishes numbered releases on GitHub. Whichever you choose, record the version you will run, track the project's security announcements, and schedule upgrades in a test environment that mirrors your header-based applications.
How PingAccess policies map to proxy rules
Start with a complete inventory of PingAccess objects before choosing any proxy configuration. Export or document each application, its site (the backend it protects), each rule that gates access, and each identity mapping that turns directory attributes into something a rule can test. Record the path patterns, HTTP methods, required groups or attributes, and whether a rule is applied to the whole application or to specific resources. Confirm the export format and what it omits with Ping's documentation and your own administrators, since the configuration will not carry over as a file. Each row in this inventory becomes one of three targets: a route in the proxy, a policy expressed as attributes, or a group check against the identity provider's claims.
Translate in that order. A PingAccess application and its site usually become a Pomerium route, with the upstream address and the public hostname set explicitly. Group-based rules map to policies that test claims from your identity provider, such as Keycloak or authentik group memberships, and where a rule depends on a user attribute rather than a group, the attribute must be present in the token or the proxy cannot evaluate it. Rules that rely on PingAccess-specific constructs, such as custom rule types, identity mapping scripts, or header injection tied to a particular PingAccess token provider, need a manual rewrite. Pomerium's Rego policies are reserved for its Enterprise edition, so plan the Core equivalent using its supported policy fields, and ask the vendor which constructs are available in your edition before committing to a design.
Test each rule before moving production traffic. Build a matrix of test users, one per group or attribute combination, and call every route with allowed and denied cases, including path variants and unauthenticated requests. Compare each result with the PingAccess response recorded during the inventory, and treat any difference as a defect until it is explained. Pay special attention to header-based applications, because the backend may trust identity headers that the proxy now sets, and confirm the proxy strips client-supplied copies of those headers. Keep the matrix as evidence for the cutover record, and repeat the run after any identity provider change.
Running header-based and legacy apps behind the proxy
Some internal applications take the user's identity from request headers, such as a username or group list, that the gateway adds after it authenticates the user. The proxy must remove any copy of those headers sent by the client, then set them from the verified session and forward only the headers the application expects. The application must accept identity headers only when they arrive through the proxy. Header names, separators for multi-valued group fields and encoding are often undocumented in legacy code, so record them in the migration inventory before cutover.
- Strip inbound copies: The proxy must discard identity headers from the client before setting its own, or a browser can claim to be an administrator.
- Map claims to headers: Decide which OIDC claims become headers, such as username, email and groups, and confirm how the application parses multiple groups.
- Trust boundary in the app: Limit trust to the proxy's network path, for example a fixed upstream address or a shared secret header, and reject requests that lack it.
- Spoofing risk: If the application listens on an address or port reachable without the proxy, any caller can send headers such as
X-Forwarded-Userand act as any user. - Session alignment: Header identity should last no longer than the proxy session, so confirm the application does not cache it beyond that.
Confirm the exact header behavior in the Pomerium or authentik proxy documentation for your chosen version, then test the application directly and through the proxy with forged headers.
Many legacy applications issue their own session cookie after login and check it on every request. When a proxy sits in front, either the proxy handles login and passes a verified identity forward, or the application sends users to the proxy and then trusts its own cookie. Cookie name, domain, path, SameSite and Secure attributes, and session lifetimes interact with the proxy's cookie, and mismatches often appear only after cutover.
- Cookie scope: Proxy cookies and application cookies must not share a name or overlap in domain and path.
- Double login: Users may see two login prompts if the application keeps its own form, so decide which layer owns authentication.
- Session lifetimes: Set the proxy session duration and the application's idle timeout deliberately, because an application session can outlive a revoked proxy session.
- Redirects and WebSockets: Legacy apps often build absolute redirect URLs from an internal hostname, which fails behind a public one. Test redirects and WebSocket upgrades.
- Cookie attributes: Confirm that Secure, HttpOnly and SameSite values survive the proxy hop unchanged.
Verify that logout clears both the proxy cookie and the application cookie, and that revoking a user's session ends access at both layers.
APIs typically receive an access token in the Authorization header. The proxy can check a token before forwarding a request, but the API must still validate the token itself, because a request can reach it by a path that skips the proxy. Keycloak issues OIDC access tokens with issuer and audience claims, so the API should check the issuer, audience, signature and expiry on every call. Decide early whether the proxy forwards the user's token unchanged or exchanges it for a service token, because the choice determines what the API can trust and how audit logs read.
- Pass the token unchanged: Confirm that the proxy forwards the Authorization header without stripping or replacing it, unless an exchange is intended.
- Validate at the API: Check issuer, audience, signature keys and expiry in the API code or framework so direct calls with bad tokens fail.
- Audience per API: Assign distinct audiences in Keycloak so a token issued for one API is rejected by another.
- Non-browser clients: Scripts and service accounts cannot complete a browser login, so plan client credentials flows and keep them separate from user traffic.
- Key rotation: Confirm the API fetches signing keys from the identity provider's published key set and handles rotation without a restart.
Send expired, wrong-audience and unsigned tokens directly to the API and through the proxy, and confirm that the API rejects all of them.
Cutover steps: moving apps off PingAccess
The sequence turns PingAccess protections into a tested Pomerium or authentik proxy setup, one application at a time, so each switch can be reversed before PingAccess is retired.
Inventory applications, routes and access rules
The security or platform team lists every application, hostname, path and API route that PingAccess protects, along with the rule set applied to each: identity source, required groups or attributes, session settings and any header injection to backends. Ask the PingAccess administrator to export the current configuration and mark which rules rely on PingAccess-specific features, such as token mediators or custom site authenticators, so they can be mapped by hand. The step is done when every protected route has one owner, one rule owner and a documented policy in plain language that a reviewer can check against the proposed proxy policy.
Build the proxy and identity provider in non-production
Stand up the chosen identity-aware proxy, such as Pomerium Core or the proxy provider in authentik, together with the self-hosted identity provider in a non-production environment that mirrors production network paths. Connect the identity provider to the same user source used today, whether directory federation or a copy of users, and confirm that the proxy can reach each backend. Check the vendor documentation for the exact configuration keys and supported identity providers before assuming a match. The step is done when a test user can reach a sample route through the proxy and the policy engine returns the expected allow and deny decisions.
Migrate one low-risk application first
Choose an internal application with few users, no regulated data and a clear business owner, then recreate its policy and header behavior in the new proxy. Where the application reads identity from headers set by PingAccess, document each header name, source claim and encoding, and confirm the backend trusts only the proxy's values, not values sent by the client. Keep the PingAccess route in place and build the new route beside it. The step is done when the owner signs off on a written test script covering the checks in the next step and the application runs against the new route in the non-production environment.
Test login, logout and session timeout
Run the same scripted scenarios against the old and new routes: first sign-in with a user in each relevant group, a denied sign-in for a user outside the group, sign-out from the application and from the identity provider, and session expiry after the idle and absolute timeouts configured in each system. Confirm that a logout clears the proxy session and that a browser back navigation does not reopen a protected page. Record the observed timeout values, because the two products may define idle and absolute timeouts differently. The step is done when every scenario passes and the differences in timeout behavior are written down and accepted by the owner.
Test header values and API token handling
Compare the headers received by the backend on the old and new routes for the same user, including the user identifier, email, group claims and any custom values. Check encoding, character sets for non-ASCII names and the case of header names, since backends often compare them literally. For API routes, send requests with bearer tokens issued by the identity provider and confirm that the proxy validates signature, audience, issuer and expiry, that expired or wrong-audience tokens are refused, and that tokens are not forwarded to backends that should not see them. The step is done when the backend logs show the same identity fields for the same user and the API test cases produce the expected status codes.
Test failure behavior and run both gateways in parallel
Simulate identity provider outages, proxy restarts, expired certificates and a backend that is unreachable, and record what users see and whether the proxy fails closed. Then run both gateways in parallel and move traffic with DNS changes or route switching, starting with a small share of users where the platform allows it, while keeping the PingAccess route ready to reverse. Watch access logs, error rates and audit entries on both paths during the overlap. Confirm that the reversal procedure has been rehearsed and that a named person can execute it. The step is done when failures are denied rather than passed through, the rollback has been tested, and the overlap period has no unexplained denials.
Retire PingAccess after the last route moves
Once every application has run on the new proxy through the parallel period, disable the PingAccess routes first and keep the configuration archive for the agreed retention period set by the organization's records policy. Remove the PingAccess site authenticators, identity mappings and certificates that are no longer used, and update the asset inventory, architecture diagrams and runbooks. Ask the PingAccess vendor to confirm the license and support terms for the period you still hold the product, and cancel renewals only after the archive is verified. The step is done when no traffic reaches PingAccess, the archive has been restored in a test, and the operations team has signed off on the updated documentation.
Questions buyers ask before replacing PingAccess
What does replacing PingAccess cost, and which parts are paid?
The cost has five components: software licenses, infrastructure, implementation, testing and ongoing operations. Open-source Pomerium Core is Apache-2.0 and authentik's open-source edition is MIT licensed, so the license line can be zero for the core software. Pomerium's pricing page lists Core as open source and self-run, while its Zero Business plan is listed at $9 per user per month billed monthly or $7 billed annually, and Enterprise is custom priced. authentik's pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually. Infrastructure, staff time and any support subscription are paid separately, and they recur. Ask each vendor which features you need are in the free tier before comparing.
What makes the migration effort go up or down?
Effort follows the number of applications, how they authenticate and how many access rules they need. Applications that already speak OIDC or SAML need less work than header-based apps, which depend on a proxy to inject identity headers, and those headers must be checked for spoofing at every hop. Custom policy logic, such as device posture checks or per-route attribute rules, adds design and testing time. Count applications by authentication method, list each PingAccess rule set, and note any dependencies on specific headers before estimating scope.
How long does a PingAccess replacement take?
Duration depends on scope, not on a fixed number. A project with a few applications on one identity provider usually moves faster than one with dozens of header-based apps, several identity sources and strict audit evidence requirements. The phases that most often extend the schedule are policy mapping, testing of header-based apps and the parallel run before cutover. DeployOpen plans timelines in a written scope agreed before work starts, so ask for phase-level milestones rather than a single total.
Can our own team run this migration without a partner?
Yes, if the team has experience with reverse proxies, OIDC, TLS and Kubernetes or VM operations, and the scope is limited. Pomerium Core and authentik can be deployed in your own environment, and both publish documentation for Docker Compose and Kubernetes installation. Teams without that experience usually need help with policy translation, hardening and cutover testing. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your infrastructure, and it can work alongside your staff or hand over the runbooks.
Which parts of the PingAccess setup are hardest to map?
The hardest parts are usually header-based applications, path-level policies and session behavior. Map every PingAccess rule to a Pomerium policy or an authentik proxy provider setting, then test what each application receives in headers after login. Also confirm how logout, token refresh and session timeouts behave, because a mismatch can leave users signed in longer than intended. Keep a test matrix for each application that covers allowed and denied users, expired sessions and direct access attempts that bypass the proxy.
What should we confirm with each vendor before signing?
Confirm which edition includes the features you rely on, since Pomerium reserves directory sync, Rego policies, RBAC for administrators and session management for its Enterprise edition, and authentik reserves Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication and enhanced audit logging for its Enterprise tier. Ask about supported versions and security release notice, which authentik documents in its security policy. Check Pomerium's current license terms for Core and the Zero plan limits on routes, policies and clusters. Get written answers on support windows and upgrade paths before you commit.
What compliance evidence does the engagement produce?
DeployOpen prepares systems, controls and evidence for compliance assessments, including access policy documentation, configuration records and test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so ask your auditor which evidence formats they accept before the project starts. Plan to keep access logs and policy change records from the parallel run onward, since auditors often ask to see how access decisions were made during the transition.
Running the proxy alongside Ping and the rest of the suite
Replacing PingAccess rarely happens in one step. During transition, the identity source, the session layer and the existing SSO connections all have to coexist, and each overlap creates a decision the team must make before cutover.
Keep Ping as the identity source
During transition, PingFederate or PingOne can stay the authoritative identity source while the proxy moves to Keycloak or authentik as a second identity provider. Decide which system issues the login for each application group and whether users are matched by a stable identifier such as a subject or email claim. Confirm that claim values are identical in both systems before routing any user.
Point the proxy at the new provider
Pomerium uses OAuth 2.0 and OIDC and lists Keycloak among its supported identity providers, so the proxy can be reconfigured to trust Keycloak while Ping still serves other relying parties. Changing the identity provider for one route at a time keeps the blast radius small. Check that the new provider's redirect URIs and client secrets are registered before the switch.
Keep existing SSO connections running
Applications already federated through PingFederate continue to need their SAML or OIDC connections while the proxy is replaced. Decide whether each connection moves to the new provider in the same wave as its proxied route, or stays on Ping until its own migration. Map which connections depend on the proxy and which authenticate directly, because only the proxied ones change at cutover.
Resolve duplicate sessions
A user can hold a Ping session and a Keycloak or authentik session at the same time, and each may prompt for MFA. Decide whether the proxy honors upstream single sign-on sessions, whether users see a second login prompt during transition, and how logout in one system reaches the other. Test sign-out from each side before users are moved in bulk.
Align token lifetimes
Access tokens, refresh tokens and proxy session lifetimes are set in different places and rarely match. A short token issued by one provider and a longer proxy session can leave users inside an app with an expired upstream credential. Decide one lifetime policy per application, document where each value is configured, and confirm the proxy refreshes or re-authenticates as intended.
Avoid cookie domain conflicts
The proxy and the identity provider set cookies that can collide when they share a parent domain or when both are reached through the same host. Decide the cookie domain, path and SameSite settings for each component, and confirm that Ping cookies do not overwrite proxy cookies on shared hostnames. Test a full login, logout and session refresh in a browser on each protected route.
What to test before cutover
Cutover from PingAccess to an identity-aware proxy is only safe when each route has been tested against the same decisions PingAccess made before. Build a test matrix with one row per protected route and one column per test category: authentication and authorization per route (unauthenticated requests redirected, authenticated users allowed only where the old rule allowed them, and group or claim checks rejecting users outside the group), header and claim correctness (the upstream app receives the identity headers or the Authorization token it expects, with the same user name, email and group values), and API token forwarding (bearer tokens reach APIs unchanged where the app validates them itself, and are not forwarded where the proxy is meant to terminate trust). Run each row against the old PingAccess path and the new proxy path, and record any difference as a defect or as an approved change.
The remaining categories cover behavior over time and under stress. Test session expiry and logout: confirm idle and absolute timeouts, that logout clears the proxy session and the identity provider session where the design requires it, and that a second browser tab cannot keep using a revoked session. Test load on the proxy with traffic shaped like production peaks, and watch latency, connection counts and error rates on the proxy and on the identity provider's token endpoint. Test certificate and TLS handling: certificate chains for each public hostname, upstream certificate validation, renewal automation and the behavior when a certificate expires in a staging run. Test audit logging: confirm each allow and deny decision is logged with user, route, time and outcome, and that logs leave the proxy host in the format your SIEM expects.
Test evidence supports change records and compliance readiness, so store the matrix, run dates, configuration versions and defect records with the change ticket. DeployOpen can prepare that evidence and map it to your internal control set, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations. Before you start, confirm with your team which route rules and identity provider settings are authoritative, and check the current release notes for the proxy and identity provider you choose, since behavior around headers, tokens and sessions can change between versions.
How DeployOpen scopes and delivers a PingAccess replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For an open-source alternative to PingAccess, that means mapping your existing access policies and protected applications to an identity-aware proxy and a self-hosted identity provider, then testing and handing over the result in writing.
How we scope
- Inventory every application, hostname and path that PingAccess currently protects, with its owner and access rules
- Record which headers, cookies and session behaviors each backend depends on before any policy is moved
- Agree the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope
How we build
- Translate PingAccess policies into proxy routes, identity provider groups and attribute-based rules, noting any gaps
- Integrate the proxy with the chosen identity provider and your directory, and configure header-based apps for each backend
- Harden the deployment and test authentication, authorization, logging and failure behavior against the agreed inventory
How we hand over
- Document the architecture, route and policy mapping, configuration and runbooks in a form your team can maintain
- Set up backups for the identity provider database and proxy configuration, and document the restore steps
- Run a cutover rehearsal with you, with a rollback plan for each application, before traffic moves
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan upgrades of the proxy and identity provider against their published release and security policies
- Prepare systems and evidence for compliance assessments, while independent auditors issue any audit reports
