Using Twingate to Control SaaS App Access

As an alternative to IP whitelisting within individual SaaS applications, you can use Twingate to add IP whitelisting rules directly to your identity provider’s authentication rules. By restricting IdP authentication to authorized Twingate users, this allows you to:

• Extend consistent Twingate authorization controls across both SaaS and private applications.
• Enable IP whitelisting for SaaS applications that do not natively support it.
• Consolidate IP whitelisting settings away from individual SaaS applications into a single combined IdP+Twingate configuration.
• Implement consistent device restrictions using Twingate across any platform.

Configuration Summary & Prerequisites

We’ve included IdP-specific instructions under “What’s Next”, below, but these are the general set of steps to follow:

• Choose a Remote network to pass IdP authentication traffic through. This will not be a significant amount of traffic, since only authentication requests to your IdP will pass through this Remote network, but this traffic will exit to the Internet via Connectors that you have deployed, so outbound Internet traffic must be allowed.

• Determine the external IP address for traffic exiting your chosen Remote network. Traffic bound for your IdP will originate from Connectors you have deployed, so if you don’t know the Internet-visible external exit IP for this traffic, you’ll need to determine this in order to configure your IdP. A simple way to do this is to add a rule in your chosen Remote network for a public website that displays your IP address, for example, *.whatsmyip.org. Accessing this destination address while connected to Twingate will reveal the public IP address of traffic exiting this Remote network.

• If you have multiple Connectors deployed, we recommend using NAT to present a single public IP address. User traffic is balanced across all available Connectors in a Remote network, and so we recommend using a NAT gateway between your deployed Connectors and outbound internet traffic so that you do not need to manage multiple public IPs.

• Add your IdP’s authentication FQDN as a Resource in the same Remote network. You can then authorize users to access this endpoint. The end result is that only users that are authorized to access this endpoint via Twingate will be allowed to access SaaS applications gated by this IdP rule.

• Apply a Device-only Policy to Your IdP Resource. A Device-only Resource Policy, when applied to the IdP Resource (e.g., tenant.okta.com, login.microsoftonline.com), allows users to route traffic through the Connector to access the IdP login portal without authentication dependencies that can create access loops. This policy prevents the common “chicken-or-egg” scenario, where users can’t authenticate with the IdP because network access to the IdP portal requires prior authentication via Twingate. By allowing users to reach the IdP through a Device-only policy, they can meet sign-on requirements without encountering this authentication loop.

• For the chosen SaaS application(s), configure your IdP authentication policy to only authorize access from your external exit IP address. This is the publicly-visible exit IP address that you determined in the previous steps. IdP-specific instructions are linked to below.

IdP-specific Instructions

• App Gating with Okta
• App Gating with Jumpcloud
• App Gating with OneLogin
• App Gating with Microsoft Entra ID (formerly Azure Active Directory)
• App Gating Best Practices
• App Gating with Google Workspace