Calling On-Premises Web Services From the Cloud, Securely

Key takeaways

• Never expose an internal SOAP or REST service directly to the internet; terminate traffic at a gateway you control.
• Authenticate the calling workload (mTLS, private_key_jwt) separately from the user it acts for.
• Use OAuth token exchange (RFC 8693) or a security token service to mint a narrow token for the internal audience.

Most organizations that moved to the cloud did not move everything. The order system, the HR database or a mainframe integration still sits in a data center, and the shiny new SaaS workflow needs to call it. The question has been around since the first hybrid deployments, and the answer has improved a lot since the days of shipping SAML tokens inside SOAP envelopes.

What is the problem with calling on-premises services from the cloud?

The internal service was built to trust its network, and a cloud caller is, by definition, outside that network.

Many internal web services authenticate weakly or not at all. They assume that anything that can reach them has already passed the corporate firewall. Some accept a username in a header. Others use a shared service account whose password has not changed in years. Opening a port so a cloud function can reach them turns those assumptions into vulnerabilities.

There are really three separate questions:

1. How does the traffic get there? Through a private link, a VPN, an outbound tunnel agent or a public gateway.
2. Who is the caller? The specific cloud workload, not just "something in the provider's IP range".
3. On whose behalf? The end user, if the call is part of a user's action, so the internal service can apply its own authorization and audit.

What does a sound hybrid architecture look like?

A gateway at the edge of your network authenticates the workload, validates or exchanges a token for the user, and forwards a narrow request to the internal service.

A typical pattern in 2026:

1. The cloud application authenticates its user with OpenID Connect and holds an access token for its own API.
2. When it needs internal data, it calls a token endpoint and asks for a new token whose audience is the internal service, using OAuth 2.0 Token Exchange (RFC 8693). It authenticates itself with mutual TLS (RFC 8705) or a signed JWT assertion (private_key_jwt).
3. It sends the request with that token to an API gateway in your perimeter or reachable over a private connection.
4. The gateway validates the token's signature, issuer, audience and expiry, applies rate limits and schema checks, and forwards the call.
5. If the backend is a legacy SOAP service, the gateway translates: it might attach a WS-Security header or call an internal security token service that issues the SAML assertion the service was built to accept.

Outbound tunnel agents are worth a mention. Several vendors and cloud providers offer a small connector that runs inside your network and dials out to the cloud, so no inbound firewall rule is needed. That solves the connectivity part, but you still need the identity parts above.

Why not forward the user's password or a long-lived service key?

Because any component that holds a reusable secret becomes a target, and forwarded passwords defeat MFA, auditing and revocation.

Password forwarding was common in early hybrid integrations and still shows up in quick fixes. It means the cloud system sees the plain password, the internal service cannot tell an interactive login from a script, and changing the password breaks the integration. A long-lived API key shared between environments has similar problems: it rarely rotates, and when it leaks there is no user context in the logs.

Short-lived, audience-restricted tokens fix most of this. A token minted for https://orders.internal.example for five minutes is useless against the HR service and useless tomorrow.

How do I check the tokens flowing through the gateway?

Decode them in a test environment and confirm the issuer, audience, scope and lifetime match what you designed.

It is common to find that the token reaching the backend is the user's original access token, with a wide audience and an hour of lifetime, instead of the narrow exchanged one. Paste a test token into the JWT Decoder and look at aud, exp and any act claim, which RFC 8693 uses to record the acting party in delegation scenarios.

Logging matters too. The gateway should log the workload identity, the user subject and the target, without logging the token itself.

What about zero trust?

Zero trust, as NIST SP 800-207 describes it, is the same idea applied everywhere: no request is trusted because of where it comes from.

Hybrid calls are often the first place teams apply it in practice, because the cloud caller so obviously sits outside the old perimeter. Once the gateway checks identity on every call from the cloud, extending the same checks to internal callers is a smaller step. Our cloud security guide covers the wider picture, and the federation guide explains how SAML and OpenID Connect trust works between the two sides.

Questions

Can I just whitelist the cloud provider's IP ranges?

IP allowlists help as one layer, but large cloud ranges are shared by thousands of tenants, so an allowlist alone tells you very little about who is calling. Combine it with mutual TLS or signed client credentials.

Do I need to rewrite old SOAP services?

Usually not. A gateway can accept a modern OAuth access token from the cloud side and translate it into whatever the old service expects, such as a WS-Security header with a SAML token, while the service itself stays untouched.

Is a site-to-site VPN enough?

A VPN encrypts the network path but treats everything inside it as trusted. Most teams now keep the tunnel or private link and still authenticate each call, so a compromised cloud workload cannot reach every internal system.

Sources

• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• NIST SP 800-207: Zero Trust Architecture

Tagged: Cloud, API, SAML, Federation, REST, STS (security token service)