Backstage behind an authenticating proxy: when the proxy signs users in
If your organization already puts a proxy in front of internal apps, Backstage can trust that proxy's session instead of running its own sign-in flow, but only if the trust is designed on purpose. Backstage ships 19 built-in authentication providers, and proxy-based sign-in is one of several options alongside GitHub, GitLab, Google, Azure, Okta, Keycloak through generic OIDC and others. The proxy providers that ship with Backstage are AWS ALB, Google IAP and Cloudflare Access. Each of these verifies a signed identity token that the platform attaches to requests, so Backstage can check the signature before it accepts the user. oauth2-proxy is handled differently: it is a separate reverse proxy that Backstage does not verify through a built-in provider, so the trust relationship has to be designed and tested by your team.
Before choosing, confirm three things with your platform owners. First, which proxy already fronts the Backstage hostname and whether it can be configured to require sign-in for every path, including the backend API routes Backstage uses. Second, whether the proxy forwards a verifiable identity claim that maps to a user in your catalog, such as an email address or a subject identifier. Third, whether any other path reaches Backstage that bypasses the proxy, such as a cluster service address or a port-forward used during incidents. The Backstage authentication documentation describes how each provider is configured and how sign-in resolvers map the verified identity to a catalog user. Confirm exact configuration keys against the version you deploy, because provider settings change between releases.
What you need before wiring a proxy to Backstage
Each proxy path depends on the same handful of inputs: a configured proxy or load balancer, an identity source behind it, a stable hostname and a catalog that can hold the users those identities resolve to. Confirm each item before choosing between AWS ALB, Google IAP, Cloudflare Access and oauth2-proxy, because a gap in any one of them stalls sign-in at the resolver step.
Proxy or load balancer account
Each path needs an account and an active configuration on the proxy side: an Application Load Balancer with OIDC authentication enabled, an IAP-protected backend in Google Cloud, a Cloudflare Access application, or an oauth2-proxy deployment you run yourself. Ask who owns each setting, including the audience or application identifier that Backstage will verify. Confirm every proxy setting against the vendor's current documentation before you build, since console labels and defaults change between releases.
Identity source behind the proxy
The proxy only authenticates users against an identity provider you already run, such as Entra ID, Okta, Google Workspace or a SAML or OIDC directory. Decide which group or application assignment limits who can reach the portal at all. Record which claims are available (email, name, groups) because Backstage's sign-in resolvers depend on them. A missing email claim is the most common reason a proxy login succeeds but Backstage cannot match the user.
Stable public hostname with TLS
Proxy signatures, OIDC redirect URIs and cookies are bound to the hostname, so the portal address must be fixed before configuration starts. Plan a DNS record and a certificate that will not change during the rollout, and confirm that the proxy forwards the original host header to Backstage. Changing the hostname later usually means re-registering the application at the proxy and the identity provider and reissuing cookies.
Supported Backstage and Node.js versions
Start from a Backstage release line that is still receiving fixes. The versioning policy sets a monthly main release and a weekly next line, and it backports high and critical fixes to releases from the last 6 months where feasible. It also supports two adjacent even-numbered Node.js releases, which the policy lists as Node.js 22 and 24 for Backstage 1.46.0. Pin the versions you test against, and confirm the current matrix in the release policy before you install.
Catalog user model
A proxy can prove who someone is, but Backstage only grants access to users that resolve to a catalog entity. Decide how each identity maps to a User entity: by email, by an annotation, or by a provider-specific ID. Load those users from your directory or from descriptor files before go-live, and make sure group membership also appears on the entities that own teams. Without this, first sign-in fails or creates an identity with no ownership.
How proxy providers fetch the session and pass identity to Backstage
In a proxy-fronted Backstage, the authenticating proxy owns sign-in and Backstage's backend owns the decision about who the user is inside the portal. For each request, the proxy checks the user's session, attaches identity to the request, and forwards it to Backstage. The Backstage proxy auth provider runs on the backend, reads that identity from the forwarded request, and turns it into a Backstage user identity. The frontend never talks to the identity provider directly in this model. It receives the resolved user from the backend, which is why the handoff between the proxy and the backend is the part of the design that needs the most attention.
The provider does not sign users in itself. It depends on the proxy to supply a session that it can trust. Depending on the product, that session is a signed token that the proxy attaches to each request (AWS ALB and Google IAP use signed assertions that the backend verifies), or a set of identity headers that the proxy writes after it has validated a session cookie (oauth2-proxy). With oauth2-proxy, the proxy refreshes tokens with the upstream identity provider and holds session state, so the backend only sees the result. Confirm for each product how the session is refreshed, how long it lasts and what happens when the proxy cannot reach the identity provider, because those answers determine when users are asked to sign in again.
The resolved identity must then pass through a sign-in resolver that maps it to a catalog user, as covered in the sibling resolver section. The backend exposes the result to the frontend through the authenticated session, so the portal shows the signed-in user and applies permissions to that user. Plan for two checks before go-live: confirm that a request which bypasses the proxy and reaches the Backstage backend directly is rejected, and confirm that the frontend shows the user the backend resolved, not a value supplied by the browser. Both checks test whether the trust boundary between the proxy and Backstage holds.
Why AWS ALB, Google IAP and Cloudflare Access verify signatures
A proxy in front of Backstage only protects it if Backstage can tell a genuine proxy response from a forged header. The three managed proxies below each attach a signed assertion or token to the request, and Backstage has to verify it before trusting any identity inside it.
Signed assertions close the bypass
If Backstage trusts identity headers alone, anyone who can reach the Backstage backend directly can send a header claiming to be an administrator. A signed assertion or token from the proxy means the backend checks a cryptographic signature against the provider's published keys before it accepts the identity. Verification is what makes the proxy a security boundary, so confirm that every request path to the backend goes through the check.
Confirm the expected audience
Each provider issues tokens for a specific application, and the audience or application identifier in the token must match the one your Backstage deployment expects. Without this check, a valid token issued for a different application behind the same provider account could be accepted. Ask your team to record the exact audience value for each environment and to reject tokens that do not match it.
Check the issuer
The issuer claim identifies which authority signed the token, and Backstage should accept only the issuer for your proxy and tenant. Accepting tokens from any issuer that uses the same key format weakens the trust chain. Confirm the issuer string in a test token against the configuration value, and treat a mismatch as a failed sign-in rather than a fallback case.
Plan for key rotation
Providers rotate their signing keys, and Backstage must fetch the current public keys rather than a copy frozen at deployment. A rotation that is not picked up causes every sign-in to fail, while overly permissive key caching widens the window for a compromised key. Ask the provider how keys are published, how often they change, and how your Backstage instance refreshes them, then test a rotation in staging.
Read each vendor's verification guide
The exact header name, token format, key endpoint and claim names differ between AWS ALB, Google IAP and Cloudflare Access, and Backstage's provider configuration follows those details. Read each vendor's documentation on verifying the signed assertion before writing configuration, because the checks above depend on the specific fields the vendor issues. Do not copy claim names from examples without confirming them against a real token from your environment.
How to configure proxy sign-in in Backstage
This sequence places a proxy in front of Backstage so the proxy verifies who is signing in and Backstage accepts only that verified identity. Work through it in order: the network path first, then the proxy, then Backstage configuration, then tests. Each step closes with a check you can record for your security review.
Lock the backend to the proxy
Before any sign-in work, confirm the Backstage backend cannot be reached except through the proxy. For AWS ALB, restrict the backend security group so only the load balancer's security group can connect on the Backstage port. For Google IAP, keep the backend private and enforce IAP on the backend service. For Cloudflare Access, allow inbound traffic only from Cloudflare, for example through a tunnel. Your network team should confirm the settings in your environment. Done when a direct request to the backend address from outside the proxy fails to connect or times out.
Register the Backstage hostname in the proxy
In the proxy, create the listener, backend target and access policy for the Backstage hostname. Attach a policy that defines who may sign in, such as membership in a corporate identity provider group or an allowed email domain. Confirm that the callback URL the proxy uses matches the external base URL in your Backstage configuration, including the https scheme. Done when an unauthenticated browser opening the hostname is redirected to the proxy's sign-in page and never reaches Backstage directly.
Add the proxy provider block to app-config
In the production configuration file, add the auth provider block that matches your proxy: the AWS ALB, Google IAP or Cloudflare Access provider, or the proxy provider when you use oauth2-proxy. Set the audience or team values that the proxy issues, and check the Backstage authentication documentation for the exact keys your version expects. Keep client secrets and cookie secrets in environment variables, not in the file. Done when the backend starts with the provider listed in the auth configuration and logs no provider configuration errors.
Configure a resolver for verified identities
Choose a sign-in resolver that maps the verified identity from the proxy to an existing catalog user, typically by matching the email claim to a User entity. Decide in advance whether identities without a catalog entity should be refused, and keep that refusal explicit rather than letting the portal create sessions for them. Keep the resolver order and fallback behavior documented so a missing user produces a clear error. Done when a test user with a catalog entity signs in and sees the expected user reference, and a test identity without an entity is refused.
Disable guest access in production
Remove the guest provider from the production configuration, because guest access would let anyone reach the portal without the proxy's identity check. Search the production configuration for any other provider or setting that allows anonymous access to plugin routes, and remove it or document why it is required. Redeploy and confirm the production configuration loads without the guest provider. Done when an unauthenticated request to the Backstage API is refused and the guest sign-in option no longer appears on the sign-in page.
Test sign-in and a rejected direct request
Run two tests. First, sign in through the proxy with a test account that has a catalog entity and confirm that the Backstage session resolves to that user. Second, send a request to the backend that bypasses the proxy, including a forged identity header, and confirm it is rejected. If you use oauth2-proxy with cookie sessions, repeat the sign-in test after a token refresh, because cookie sessions cannot be locked and concurrent refreshes can force a new login. Done when both results match the expected outcome and you have recorded them as evidence.
Choosing between ALB, IAP, Cloudflare Access and oauth2-proxy
The Application Load Balancer runs in your AWS account in front of the Backstage backend. When OIDC authentication is enabled on a listener rule, the load balancer completes sign-in with your identity provider and forwards each request with a signed identity token. Backstage's aws-alb provider reads that token, so Backstage does not run its own session with the identity provider.
- Where it runs: inside your AWS account as a managed listener feature, so the load balancer must be the only network path to the backend.
- What it verifies: the OIDC login completed at the load balancer, with claims signed by AWS so Backstage can check them against published keys.
- Backstage side: the
aws-albprovider maps the forwarded identity to a catalog user through a sign-in resolver you configure. - Operational trade-off: there is no separate Backstage sign-in screen, sign-out depends on load balancer session behavior, and the design is tied to AWS networking.
Confirm the signature verification settings, the listener rule's session timeout, and whether your identity provider's groups reach Backstage before you rely on this path.
Identity-Aware Proxy runs on Google's edge in front of backends you register with it. It checks the user's Google identity against an access policy you define, then adds a signed JWT to each request. Backstage's gcp-iap provider verifies that assertion, so the Backstage backend trusts the identity only after the signature checks out.
- Where it runs: on Google's infrastructure, configured per backend service, so direct access to the Backstage backend must be blocked.
- What it verifies: the Google account and the IAP access policy, delivered as a signed assertion header.
- Backstage side: the
gcp-iapprovider, with a resolver that usually matches on email, so confirm that account domains match catalog entries. - Operational trade-off: Google Workspace or Cloud Identity accounts fit most directly, external identity sources need a federation setup, and access policy lives in Google Cloud, separate from Backstage permissions.
Confirm the audience value used in verification, that the backend cannot be reached without IAP, and which Google identities the access policy admits.
Cloudflare Access runs on Cloudflare's network in front of a hostname you protect. Users sign in through an identity provider connected to Access, and Cloudflare sends a signed JWT with each request to the origin. The origin must verify that token, which the Backstage cloudflare-access provider does.
- Where it runs: on Cloudflare's network, so the Backstage origin should accept traffic only from Cloudflare. Confirm the connection options for your topology.
- What it verifies: the Access application policy and the identity provider login, through a signed token whose audience tag must match the Access application.
- Backstage side: the
cloudflare-accessprovider, with a resolver that maps the token identity to a catalog user. - Operational trade-off: policy is managed in Cloudflare, which adds a third party to the request path. Review that dependency and the data flows with your privacy and procurement teams before adoption.
Confirm the audience tag, how the origin is locked to Cloudflare, and how sessions and sign-out behave for your users.
oauth2-proxy is a reverse proxy distributed under the MIT License. It is a Cloud Native Computing Foundation Sandbox project and a community-driven project. It signs users in with Google, Microsoft Entra ID, GitHub, OpenID Connect and other providers, then forwards the username, groups and email to the upstream application as HTTP headers. Backstage does not verify those headers as signed assertions by default, so the network design carries the trust decision.
- Where it runs: in your infrastructure, either as the reverse proxy or as middleware beside an existing proxy, so you own its patching and upgrades.
- Header trust:
X-Forwarded-User,X-Forwarded-GroupsandX-Forwarded-Emailcan be set by any client that reaches Backstage directly. Allow only the proxy to connect to the backend, and strip client-supplied copies of these headers at the edge. - Session storage: cookie sessions need a cookie secret and cannot be locked, so concurrent token refreshes can force users to sign in again. Redis-backed sessions keep only a ticket in the cookie.
- Release tracking: the project published v7.15.5 on October 1, 2026, so check the release notes before pinning a version.
Verify that a request with forged identity headers sent straight to Backstage is rejected, and confirm the session storage choice before go-live.
The risk with oauth2-proxy: trusting headers that anyone can send
oauth2-proxy tells the application who the user is through HTTP headers, and a header is only as trustworthy as the path it arrives on. When oauth2-proxy sits in front of Backstage, it forwards identity in headers such as X-Forwarded-User, X-Forwarded-Groups and X-Forwarded-Email. If the Backstage backend accepts those headers from any caller, a client that reaches the backend directly can send its own copy and sign in as anyone. The proxy does not stop this on its own. The protection comes from the network and the edge around it, so the platform team has to confirm each control before go-live: the Backstage backend sits on a private network with no public route, the proxy is the only ingress that can reach it, and the load balancer or ingress strips any inbound copy of the identity headers before a request reaches the proxy. Test the last point directly by sending a request with a forged X-Forwarded-User header through the public address and confirming the proxy overwrites or drops it.
Session storage is the second decision, and it trades security properties against operational behavior. By default oauth2-proxy keeps the session in an encrypted client-side cookie, which requires a cookie secret that every replica must share and that must be rotated with care. The session storage documentation notes that cookie sessions cannot be locked, so two concurrent token refreshes from the same user can conflict and force a new login. Redis, including Redis Sentinel or Redis Cluster, keeps the session server-side and leaves only a ticket in the cookie, which avoids large cookies and makes revocation possible, at the cost of running and securing a Redis dependency. Confirm with your identity team which failure you prefer: forced re-logins under concurrent refresh, or an additional stateful service in the sign-in path.
Before choosing, ask the platform team to document the header allow list, the network policy that isolates the Backstage backend, the cookie secret rotation procedure and the session store's availability target. Also confirm how the Backstage auth provider in use maps the forwarded identity to a catalog user, since a header that resolves to no catalog entity should fail closed rather than create a session. Review those answers with your security team, because they decide whether the proxy is a control or only a convenience.
Mapping proxy identity claims to Backstage catalog users
This table maps each attribute a proxy can supply (user, email, groups and the signed token or assertion) to the Backstage user entity field or resolver input it feeds, with the trust level of each. Confirm claim and header names in each provider's documentation before writing resolvers. The main takeaway: every sign-in path should resolve to the same catalog user, and proxy groups only grant access once they match catalog group entities.
| Attribute | Where the proxy supplies it | Backstage field or resolver input | Trust level |
|---|---|---|---|
| User identifier | oauth2-proxy header such as X-Forwarded-User; signed subject claim in ALB, IAP and Cloudflare Access tokens | Input to the sign-in resolver that selects the catalog user | High when read from a verified token; low when read from a plain header |
| Email address | X-Forwarded-Email in oauth2-proxy; email claim in the signed token | Email-based resolver and the allowedDomains check | Medium; confirm the identity provider marks the email as verified |
| Groups | X-Forwarded-Groups in oauth2-proxy; group claim in the signed token, if configured | Not used by default resolvers; must match Group entities referenced by the user's memberOf | Medium; depends on how the identity provider populates groups |
| Token or assertion | oauth2-proxy can forward the access or ID token; ALB, IAP and Cloudflare Access send a signed JWT | Backstage provider verifies the signature before trusting any claim | High only after signature verification succeeds |
| Cross-provider identity | Same person arriving through different proxies or direct OIDC sign-in | All providers should resolve to one catalog user, per the authentication guidance | Must be verified in testing; mismatched entities create duplicate identities |
| Group name matching | Proxy group names such as directory group IDs or display names | Group entity names in the catalog, referenced from user spec memberOf | Low until names are reconciled and tested against real users |
| Unmatched user | Valid proxy session with no corresponding catalog user entity | Resolver returns NotFoundError; guest access should stay off in production | Not applicable; denial is the expected outcome |
| Direct access bypassing the proxy | Requests that reach Backstage without passing through the proxy | Any header-based identity is accepted if the network path is open | None; restrict network access so only the proxy can reach the backend |
Security controls for a proxy-fronted Backstage
A proxy only protects Backstage if the backend cannot be reached around it and the identities it passes through are trusted. These six controls cover the path, the headers, guest access, resolvers, session secrets and sign-in logging that decide whether the proxy does its job.
Lock the backend to the proxy path
Make sure the Backstage backend accepts requests only from the proxy. If the backend is reachable directly, anyone who can send a request to it can set identity headers themselves. Check security groups, ingress rules and network policies, and test by calling the backend URL without going through the proxy. The request should be refused. Confirm this for every route that accepts sign-in, including any path the proxy does not front.
Verify signatures or restrict headers
AWS ALB and Google IAP sign the identity assertions they send upstream, and Backstage's providers check those signatures before trusting the user. Cloudflare Access works the same way with its own assertion. oauth2-proxy instead sends plain headers such as X-Forwarded-User, so anything that reaches the backend with those headers is trusted. Confirm which model you run and that the backend is unreachable except through the proxy.
Disable guest access
Guest sign-in lets anyone reach the portal without an identity from your directory. The Backstage authentication documentation advises against offering guest access in production. Confirm that the guest provider is not configured in the production app config, and that no build or environment override turns it on. Test with a user who is not in your identity provider and confirm the sign-in is refused.
Use resolvers that cannot match arbitrary users
A proxy can authenticate anyone your identity provider accepts, so the resolver decides which catalog user that person becomes. Use resolvers that match only existing catalog entities, and reject sign-ins that match nothing rather than creating a user. Avoid resolvers that trust a claim the user can influence. Confirm the resolver order and test a valid account that has no catalog entry.
Keep session secrets in a secrets store
oauth2-proxy encrypts cookie sessions with a cookie secret by default, and Redis-backed sessions keep a ticket in the cookie. Whoever holds the cookie secret can forge or decrypt sessions. Store the cookie secret, client secret and any Redis credentials in a secrets manager, not in a values file or image. Set cookie flags for secure transport and an expiry you have agreed with your security team, and rotate the secret on a schedule.
Log sign-in events
Record sign-ins, refusals and resolver failures in one place so an investigation can trace a session back to a proxy identity. Capture the user, the provider, the time and the result, and make sure the proxy and Backstage logs share a request or session identifier. Check that the logs reach your central system and that retention matches your policy. Note that proxy auth does not replace the protection needed for plugin-to-plugin and external callers, which is covered in service-to-service auth.
When a proxy also protects the frontend bundle
A proxy in front of the Backstage frontend bundle is a different control from a proxy in front of the API. The frontend bundle is static JavaScript and HTML, so protecting it hides the portal from the internet and applies one edge policy across every application your organization publishes. That policy might be a device posture check, a network restriction or a country block enforced at AWS ALB, Google IAP or Cloudflare Access before any page loads. This adds real value when the portal should not be discoverable at all, or when security teams already manage access at the edge and want the portal to follow the same rules. It does not replace the backend checks. Every call to the Backstage backend still needs the verified identity and the Backstage permission framework, because a request that reaches the API through another path, an internal network or a misconfigured route is not covered by the edge policy.
The frontend and backend may be served from different origins, and that changes how cookies and headers behave. If the proxy protects app.example.internal while the backend answers on a separate host, the session cookie, the Origin checks and the CORS settings in app-config.yaml all have to agree with the browser's view of the domains. A proxy that adds its own assertion header or session cookie on the frontend path may not send it on the backend path, which produces sign-in loops or silent 401 responses that look like a Backstage fault. Confirm with your proxy vendor which cookies and headers are set on each host and whether they are scoped to the parent domain. Then test sign-in, sign-out, token refresh, catalog reads, scaffolder runs and the /api calls from a browser on each origin, with your own identity provider and a non-admin test account, before go-live.
Plan the protected frontend as an addition to backend verification, not a substitute for it. Record which requests the proxy authenticates, which requests the Backstage backend authenticates, and what each layer does when the other is misconfigured. Re-run that test after every Backstage upgrade, because frontend routing and auth provider changes can shift which paths the proxy must allow. For the proxy-specific verification steps, see the sibling sections on each provider.
Common proxy sign-in failures and their fixes
This table lists the failures teams most often hit when Backstage sits behind AWS ALB, Google IAP, Cloudflare Access or oauth2-proxy, with the likely cause and fix for each. Read it by symptom: match what users or logs show, then check the cause column before changing configuration. Most of these failures trace to a mismatch between what the proxy sends and what Backstage expects, so verify the identity and audience settings on both sides first.
| Failure | Likely cause | Fix |
|---|---|---|
| Sign-in loop after redirect | The proxy session is not reaching Backstage, or the callback URL configured at the proxy does not match the public Backstage URL | Confirm the public base URL in the Backstage app config matches the proxy's callback host and path exactly, then check that the proxy forwards the session cookie or assertion header on every request |
| Identity resolves to no catalog user | The proxy identity (email or username) does not match any User entity, or the resolver expects a different claim than the proxy supplies | Check which claim the proxy passes, then set the sign-in resolver to match it, or add the matching annotation or email to the User entity; avoid loosening resolvers to get past the error |
| Signature verification fails after key rotation or audience mismatch | The ALB or IAP public keys rotated, or the expected audience value in Backstage does not match the one the proxy signs into the token | Refresh the key source Backstage fetches from, and confirm the audience string for the ALB target group or IAP client ID matches the configured value exactly; test with a fresh token after the change |
| Headers missing behind a load balancer | An intermediate load balancer or ingress strips or renames the identity headers, or Backstage trusts a header the proxy never sends | Trace one request through each hop, confirm the header names the proxy actually emits, and make sure only the trusted proxy can reach the backend so client-supplied headers are not accepted |
| Cookies dropped because of domain or SameSite settings | The cookie domain does not cover the Backstage host, or SameSite and Secure flags block the cookie on the redirect back from the identity provider | Set the cookie domain to the shared parent domain only where needed, confirm the Secure flag matches HTTPS termination, and test the full redirect chain in a browser with developer tools open |
| Direct-to-backend requests succeed when they should fail | The backend is reachable without going through the proxy, for example through a service address, a pod port or a public DNS record that skips the proxy | Restrict network access so only the proxy or load balancer can reach the Backstage backend, validate the identity assertion in the backend rather than trusting headers alone, and retest with requests sent straight to the backend |
Questions teams ask before choosing a proxy for Backstage sign-in
Is proxy sign-in secure enough for a production Backstage?
Yes, when the proxy is configured correctly and Backstage verifies what the proxy sends. Backstage ships built-in providers for AWS ALB, Google IAP and Cloudflare Access, and those providers check the signed assertion that the proxy attaches to each request rather than trusting a plain header. The risk sits mostly in the setup: the backend must be unreachable except through the proxy, sign-in resolvers must map every identity to a catalog user, and guest access should be off. The Backstage authentication documentation advises against guest access in production. Ask your security team to test these paths before go-live, not just the happy-path login.
How much effort does a proxy setup take, and what drives it?
The effort depends mostly on how many moving parts already exist. The main drivers are whether the proxy is already in use for other internal apps, how many identity sources feed the catalog, whether you need custom resolvers, and how cleanly your network allows traffic to reach Backstage only through the proxy. A team with an existing ALB or Cloudflare Access policy and a single directory usually has less to build than a team creating a new proxy tier. Ask any partner for a written scope that lists the proxy, the resolver logic, network rules, and the test cases, because those items set the work more than the product choice does.
Can our own team set up proxy sign-in without outside help?
A capable platform team can usually do it in-house if it has someone who knows the proxy, someone who knows Backstage configuration, and time to test edge cases. The work is mostly configuration, but the failure modes are subtle: a misrouted backend, a missing signature check, or a resolver that matches the wrong user can create access problems that only appear under specific conditions. Outside help is most useful for an independent review of the design, for the test plan, or for handling the hardening tasks that follow. Whichever path you choose, agree on who owns the proxy policy and who owns Backstage's resolvers after launch.
What do we need from our identity and network teams?
You need identity team input on the identity provider, the claims or attributes the proxy will send, and how group membership is maintained. The network team must confirm that the Backstage backend cannot be reached directly, that the proxy's source addresses or tunnel are the only path in, and that health checks and internal service calls still work. Your security team should own the decision on session lifetime and logout behavior. Put these dependencies in the plan early, because identity and network changes often have their own change-approval lead times that your project schedule must absorb.
How long does testing take, and why does it vary?
Testing length depends on your environment, and no duration can be quoted from general principles. It varies with the number of identity sources, the number of resolver rules, whether you run multiple environments, and how many user populations need to sign in. Plan test cases for valid users, users missing from the catalog, users with multiple identities, expired sessions, and direct calls that bypass the proxy. Ask any partner to show the test matrix and the environments it runs in before agreeing to a timeline.
How does oauth2-proxy compare with a cloud-native proxy?
oauth2-proxy is a reverse proxy that works with Google, Microsoft Entra ID, GitHub and generic OIDC providers, and it can forward user, group and email headers upstream. It is MIT licensed and is a CNCF Sandbox project. Cloud-native options such as AWS ALB, Google IAP and Cloudflare Access are managed services that you configure within the platform. The main difference is responsibility: with oauth2-proxy you run the proxy, manage its session store, and take on more of the header-trust design. Cookie sessions cannot be locked, so concurrent token refreshes can force re-login, and Redis-backed sessions add a service to operate. Backstage's built-in providers for the managed services verify signed assertions, which is a stronger default than trusting forwarded headers. Confirm the current oauth2-proxy release and session options in the oauth2-proxy repository before you decide.
What should a quote for proxy sign-in include?
A quote should follow from a written scope that lists each deliverable and its acceptance test. Ask for the components in scope: proxy configuration, Backstage auth provider settings, sign-in resolvers, network restrictions, test cases, documentation and handover. Ask which costs are one-time, such as the initial build and testing, and which recur, such as proxy licensing or cloud charges, upgrades and support. Ask who pays for the managed proxy service, and whether any identity provider changes fall outside the quote. DeployOpen plans engagements on fixed scope agreed in writing before work starts, and it does not publish a price list, so a quote follows from that scope.
How DeployOpen scopes and delivers proxy-based Backstage sign-in
DeployOpen plans and builds Backstage sign-in behind an authenticating proxy inside your own infrastructure, from the proxy configuration to the resolver that maps each verified identity to a catalog user. Engagements start with a written scope that names the proxy, the identity source and the access model before any build work begins.
How we scope
- Written scope names the proxy (AWS ALB, Google IAP, Cloudflare Access or oauth2-proxy) and the identity source behind it.
- Scope records which headers or assertions Backstage will trust, and which signature or token checks protect them.
- Fixed-scope agreements list deliverables, timelines and exclusions before any work starts, with a quote following from that scope.
How we build
- We configure the proxy provider and verify signatures or tokens against the proxy's published keys in a test environment first.
- We write and test sign-in resolvers so every verified identity maps to one catalog user, with no guest access in production.
- We confirm that direct requests bypassing the proxy are rejected, and document how the frontend bundle is protected or left public.
How we hand over
- You receive configuration, resolver code, test cases and a runbook covering key rotation, session handling and proxy changes.
- Documentation explains which trust boundary each component enforces, so your security team can review it independently.
- Handover includes a walkthrough with the engineers who will operate the sign-in path after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering Backstage and proxy version changes.
- Retainers can include reviewing proxy and Backstage release notes that affect the sign-in path before you upgrade.
- Confirm with your proxy vendor or project which versions and features apply to your environment before scoping work.
