Descope’s on-premises B2B identity model exposes static key risk

At a glance

What this is: This is a deployment guide for using Descope in on-premises and hybrid B2B environments, with a clear emphasis on static API keys, secure connectivity, and SSO integration.

Why it matters: It matters because hybrid identity deployments widen the NHI and access-governance surface, especially where customer-hosted infrastructure, tunnel-based connectivity, and long-lived credentials must be controlled together.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Descope's guide to on-premises B2B identity deployment

Context

Hybrid B2B identity deployments rely on the same core controls as cloud identity, but they introduce a harder governance problem because authentication, provisioning, redirects, and event delivery may span customer-owned infrastructure and a vendor-hosted identity service. In that setup, the primary risk is not just whether the login flow works, but whether every credential, callback, and network path has a clear trust boundary.

The article focuses on how to make those integrations work in practice through static project keys, firewall rules, reverse tunnels, and customer-managed identity providers such as ADFS. That is a classic non-human identity problem: service credentials and integration points must be isolated, rotated, and monitored even when the application itself is installed on premises.

For IAM teams, the deeper question is how to preserve enterprise-grade controls such as SSO, MFA, auditability, and offboarding when the deployment model is distributed across tenants, private VPCs, and temporary tunnel endpoints. The starting assumption is typical for modern SaaS delivery, but the governance burden is materially higher than in a single-cloud deployment.

Key questions

Q: How should security teams handle API keys and tokens as part of identity governance?

A: Security teams should treat API keys and tokens as governed identities, not just technical secrets. That means assigning ownership, defining scope, logging use, and removing credentials when the business process ends. The same lifecycle logic used for service accounts applies here, because stale API credentials are a common path to misuse and data exposure.

Q: Why do on-premises SSO and webhook integrations increase identity risk?

A: They increase risk because authentication now depends on both credential handling and network trust. Redirects, callbacks, and webhooks create a bidirectional path that can be misconfigured, overexposed, or left unclearly owned. Security teams should therefore evaluate IAM controls and ingress policy together, not as separate workstreams.

Q: What breaks when reverse tunnels become the default for identity traffic?

A: The main failure is control drift. A tunnel that begins as a convenience can become a persistent, externally reachable identity path with weak ownership, unclear uptime monitoring, and broad callback exposure. That creates a hidden dependency in the authentication flow and makes incident containment slower when the tunnel changes or fails.

Q: How do hybrid identity teams decide between direct network rules and tunnels?

A: Use direct network rules for production when the customer environment can support stable allowlisting and route ownership. Use tunnels only for testing or constrained deployments where the exception is explicitly documented and monitored. The decision should be based on governability, not convenience alone.

Technical breakdown

Static API keys in hybrid deployments

Hybrid and on-premises B2B identity integrations often use a dedicated project and static API key per customer so the application can call the identity platform from a private environment. That pattern improves isolation compared with shared credentials, but the key is still a long-lived non-human identity that can be copied, stored in environment variables, and reused until revoked. The security model therefore depends on clean tenant separation, revocation speed, and logging that can distinguish one customer deployment from another.

Practical implication: treat each customer project key as a governed NHI credential with ownership, rotation, and revocation controls.

Why redirect and webhook paths need tight network scoping

On-premises SSO, OAuth callbacks, and webhook delivery require bidirectional connectivity. Outbound requests from the customer environment validate sessions and retrieve hosted assets, while inbound requests from the identity provider deliver redirect responses and event notifications. If these paths are left broadly open, the integration surface becomes harder to reason about because authentication traffic, operational webhooks, and application callbacks share the same network trust model. Allowlisting only the required domains and routes narrows that exposure.

Practical implication: scope callback and webhook routes explicitly, and do not treat broad inbound HTTPS access as an acceptable default.

Reverse tunnels as a controlled exception, not a default pattern

Reverse proxies and tunnels such as ngrok or Cloudflare Tunnel can solve connectivity problems when firewall changes are impossible, but they change the trust model from internal network access to externally reachable relay infrastructure. That can be acceptable for testing or constrained environments, yet it creates dependency on persistent URL management, certificate validation, and tunnel uptime. In identity terms, the tunnel becomes part of the authentication path and therefore part of the attack surface.

Practical implication: use tunnels as an exception path and monitor them as part of the identity control plane.

NHI Mgmt Group analysis

Static project keys are the core NHI governance exposure in hybrid CIAM. The article’s recommended per-customer key model is structurally safer than shared credentials, but it still leaves organisations dependent on long-lived secrets that must be distributed, stored, and revoked across customer environments. That is a classic non-human identity lifecycle problem, not just a deployment detail. The practitioner conclusion is that every on-prem deployment should be governed like a separate NHI estate.

Hybrid identity shifts the trust boundary from the app to the network path. Once redirects, SSO responses, and webhooks must traverse firewall rules or tunnels, identity assurance depends on both credential control and route control. This broadens the governance scope beyond IAM configuration into ingress policy, egress policy, and callback validation. The implication is that IAM, PAM, and network teams need a shared control model for customer-hosted deployments.

Customer-managed IdPs do not reduce identity complexity, they redistribute it. The integration with ADFS, PingFederate, ForgeRock, Shibboleth, and similar systems keeps authentication local, but it also multiplies the number of systems that can fail entitlement, attribute mapping, or lifecycle expectations. That means federation becomes a governance dependency, not a simplification. The practitioner takeaway is to verify that offboarding, rotation, and audit ownership remain explicit across both sides of the trust relationship.

Scoped connectivity is the right answer only when it remains continuously governable. Allowlisting Cloudflare ranges, pinning callback paths, and validating TLS all reduce exposure, but none of them are one-time settings. In a distributed deployment model, the security problem is drift: keys outlive purpose, routes expand, and tunnel exceptions become normalised. The field should treat hybrid identity as a governance discipline, not a transport problem.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Hybrid identity teams should pair this with OWASP NHI Top 10 guidance when agentic flows touch customer-hosted authentication paths.

What this signals

Hybrid identity will keep pushing credential governance out to the edge. The more SaaS vendors support customer-hosted deployments, the more often IAM teams will have to manage static keys, callback routes, and exception-based connectivity as part of the identity control plane. That means lifecycle discipline for non-human credentials will matter as much as federation design, especially where customer environments are privately managed.

Credential sprawl is the hidden cost of deployment flexibility. Every extra customer project, tunnel endpoint, and IdP integration adds another asset that can outlive its intended purpose. Our view is that hybrid CIAM programmes will fail first on ownership, not cryptography, because control drift happens faster than recertification cycles can catch it.

The right forward model is to treat external connectivity as a governed dependency and to align it with established identity guidance such as NIST AI Risk Management Framework only where autonomous or AI-assisted flows are introduced. For pure deployment mechanics, the more relevant posture is disciplined lifecycle management, not AI governance.

For practitioners

• Inventory every customer-specific API key Map each Descope project key to a named customer deployment, an owner, a storage location, and a revocation path. Treat the key as a non-human identity credential with lifecycle tracking, not as a generic integration setting.
• Restrict callback and webhook routes Allow inbound HTTPS only for the exact redirect and webhook endpoints needed for SSO, event delivery, and step-up flows. Review those routes alongside firewall rules and IP allowlists so authentication traffic is not mixed with broader application exposure.
• Govern tunnels as temporary identity infrastructure If reverse tunnels are required, document the approved use case, enforce certificate validation, and monitor uptime and reconnect behaviour. Do not let a tunnel become an unowned backdoor into customer-hosted authentication paths.
• Separate production connectivity from proof-of-concept access Use direct firewall rules for steady-state production and reserve tunnel-based connectivity for constrained environments where the exception is explicitly approved. That separation prevents temporary access patterns from becoming the default operating model.

Key takeaways

• Hybrid B2B identity deployments add a non-human identity lifecycle problem because static keys, tunnels, and callbacks must be governed across customer-owned environments.
• The operational scale of the issue is the trust boundary itself, since authentication, provisioning, and event delivery now depend on both network scoping and credential discipline.
• Teams should separate production connectivity from exceptions, govern every customer key individually, and treat reverse tunnels as monitored identity infrastructure rather than a convenience layer.

Key terms

• Static Project Key: A static project key is a long-lived credential that identifies a specific customer deployment or integration instance. In hybrid identity architectures it behaves like a non-human identity secret, so it needs ownership, storage controls, rotation, and revocation just like any other privileged credential.
• Reverse Tunnel: A reverse tunnel is an access path initiated by the device rather than the operator. It lets the remote system establish an outbound connection to a broker, then carry privileged sessions back through that channel when inbound access is blocked or impractical.
• Customer-Managed IdP: A customer-managed identity provider is the local authentication authority used by the customer, such as ADFS or PingFederate. It reduces dependency on cloud-hosted login flows, but it also adds federation complexity, attribute mapping risk, and lifecycle ownership across two organisations.
• Hybrid CIAM: Hybrid CIAM is a customer identity and access model that must work across cloud-hosted and on-premises environments. It combines authentication, provisioning, auditability, and network connectivity requirements, which means governance has to cover both identity lifecycle and deployment topology.

What's in the full article

Descope's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step setup for customer-specific project keys, including console navigation and secret distribution.
• Exact firewall, ACL, and proxy requirements for production SSO, hosted flows, and webhook delivery.
• ngrok and Cloudflare Tunnel configuration steps for testing and constrained deployment scenarios.
• On-premises IdP setup details for ADFS, PingFederate, ForgeRock, Shibboleth, and Keycloak.

👉 The full Descope guide covers network rules, tunnel options, and on-premises SSO setup in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.