Network flow matrix (SSO / firewall)
This page lists the network flows to allow so that FoxPlan and single sign-on (SSO) work correctly, in particular behind a VPN, a corporate proxy or a firewall performing SSL inspection.
It covers every supported SSO provider: Microsoft / Entra ID, Google, Atlassian (Jira), Okta and any custom OIDC provider (including Keycloak).
How to read this matrix
An SSO sign-in involves two distinct categories of flow:
- Browser flows — issued from the user's device (the provider's sign-in page, the return to FoxPlan). These are the ones that go through the user's VPN / proxy and, when blocked, cause sign-in failures or loops.
- Server flows — issued by the FoxPlan backend to the identity provider (token exchange, signing keys, user profile). In SaaS, these calls originate from FoxPlan's infrastructure and do not concern the customer's firewall. In on-premise, the customer's FoxPlan server must issue them outbound.
All flows are HTTPS (TCP/443).
SSO relies on a state cookie (oauth2_auth_request, SameSite=Lax, Secure). A proxy that strips, rewrites or inspects this cookie prevents FoxPlan from validating the return: the page loops. The domains below must be allowed without SSL inspection or cookie rewriting.
Browser flows (user device → Internet)
These flows go through the user's VPN / proxy. Allow them on the devices. All are over HTTPS (TCP/443). Only allow the row(s) matching the SSO provider(s) you use.
| Provider | Domains to allow (sign-in page + assets) |
|---|---|
| FoxPlan (always) | app.fox-plan.com |
| Microsoft / Entra ID | login.microsoftonline.com, login.microsoft.com, login.live.com, *.msftauth.net, *.msauth.net, *.msauthimages.net |
accounts.google.com, ssl.gstatic.com, fonts.gstatic.com | |
| Atlassian / Jira | auth.atlassian.com |
| Okta | <your-tenant>.okta.com, *.oktacdn.com |
| Custom OIDC / Keycloak | your identity provider domain |
The CSS, images and fonts of the sign-in page are loaded by the provider's page, on its own domain (Microsoft, Google…), and not by FoxPlan — which is never part of that step. They belong to the same provider identity endpoint group: allowing that group via the provider's official list (see "Official references" below) covers them. No need to handle them as separate flows.
login.microsoftonline.com is also used for server-side token exchange (see the next section).
Server flows (FoxPlan backend → identity provider)
In SaaS, these flows originate from FoxPlan's infrastructure and do not need to be opened on the customer's firewall. In on-premise, they must be allowed outbound from the FoxPlan server.
| Domain (FQDN) | Port | Role | Provider |
|---|---|---|---|
login.microsoftonline.com | 443 | Token exchange + signing keys (JWKS) | Microsoft |
graph.microsoft.com | 443 | User profile (userinfo) | Microsoft |
accounts.google.com | 443 | OIDC discovery / keys (JWKS) | |
oauth2.googleapis.com | 443 | Token exchange | |
www.googleapis.com | 443 | Signing keys (JWKS) | |
openidconnect.googleapis.com | 443 | User profile (userinfo) | |
auth.atlassian.com | 443 | Token exchange | Atlassian |
api.atlassian.com | 443 | User profile (/me) | Atlassian |
<your-tenant>.okta.com | 443 | Token, keys (JWKS), userinfo | Okta |
| Your IdP domain | 443 | Token, keys (JWKS), userinfo | Keycloak / custom OIDC |
Inbound flows (identity provider → FoxPlan)
No inbound server flow is initiated by the identity provider toward FoxPlan. The sign-in "return" (OIDC authorization code) is carried by the user's browser to app.fox-plan.com (already covered by the browser flows above), not by a connection issued from the provider's servers.
Firewall implication: there is no need to open an inbound rule from the provider's address ranges (Microsoft, Google, Okta…) toward FoxPlan.
FoxPlan implements no back-channel logout: no other inbound flow from the IdP is expected.
Application flows (excluding SSO)
Beyond SSO, the FoxPlan application uses the following browser flows (HTTPS/443).
Required for the application to work properly:
| Domain (FQDN) | Role |
|---|---|
app.fox-plan.com | Application and documentation (/docs) |
The FoxPlan interface uses no remote fonts (no Google Fonts): it bundles its fonts, so no extra flow is required for rendering.
Optional — the application works without them; blocking them only disables the related feature:
| Domain (FQDN) | Role | If blocked |
|---|---|---|
js.hs-scripts.com, js.hs-analytics.net, js.hs-banner.com, js.hscollectedforms.net, js.hsadspixel.net, js.usemessages.com | HubSpot (support / analytics) | No HubSpot widget |
- Audience measurement: performed server-side via Plausible; the browser loads no third-party analytics script (Google Tag Manager / Analytics have been removed).
- Error reporting (Sentry): the browser SDK sends its events to our own API (
/api/commons/sentry-tunnel, a first-party tunnel) and the backend relays them to the Sentry ingest — so the browser does not contactingest.sentry.io.
Both are server-side outbound flows (FoxPlan infrastructure in SaaS, no impact on the customer's firewall; in on-premise, Plausible only happens if configured).
In SaaS, the server-side outbound flows (email delivery, object file storage, notifications, server error reporting, Plausible audience measurement) originate from FoxPlan's infrastructure and do not concern the customer's firewall. In on-premise, allow HTTPS egress from the FoxPlan server to the services you configure (email provider, S3 object storage, Plausible if applicable, etc.).
VPN / proxy / firewall watch points
- Do not SSL-inspect or rewrite cookies on
app.fox-plan.comor on the identity domains: this is the #1 cause of SSO sign-ins that "loop". - Allow the domains above on TCP/443, without a proxy authentication interstitial (captive portal) on the return flow.
- Split-tunnel: if the proxy cannot be adjusted, exclude these domains from the VPN tunnel.
- Do not truncate responses: identity responses (tokens) can exceed 8 KB; provide sufficient buffers on the proxy side.
- Allow redirects between
app.fox-plan.comand the provider domain (302) without URL rewriting.
Official references
Host lists change over time; refer to each provider's official source:
- Microsoft / Entra ID — endpoint sets 56 (identity) and 59 (sign-in assets) of the official Microsoft 365 URLs and IP address ranges.
- Google — endpoints published in Google's OpenID configuration.
- Atlassian — Atlassian OAuth 2.0 (3LO) documentation.
- Okta — endpoints of your Okta domain (
https://<your-tenant>.okta.com/.well-known/openid-configuration).
When self-hosting, replace app.fox-plan.com with your own domain. Internal flows (MongoDB database, Redis cache, internal services) stay inside the cluster and are not covered by this matrix — see On-premise (Kubernetes / Docker).