SSO and SAML for VPN Access: Signing In Through the Company Identity Provider

SSO (single sign-on) means a staff member authenticates once against the company identity provider, and the VPN, like every other work app, accepts that result without keeping its own password for the user. SAML is one of the protocols carrying this verdict from the provider to the VPN; OIDC is the other. In practice the gatekeeper is a product like Okta, Entra ID or Google Workspace, and the VPN gateway trusts nothing but its signature.

SSO and SAML are not the same thing

Vendors print both words side by side on pricing pages, which is why people mix them up. SSO covers the outcome: one company login for many applications. SAML 2.0, an OASIS standard from 2005, covers one way to deliver it. The OASIS SAML 2.0 technical overview describes the two roles: the identity provider (IdP), which stores users, checks passwords and MFA, and issues a signed statement; and the service provider (SP), which trusts it. For a VPN, the SP is the gateway or the vendor's admin console. OIDC does the same job in a different format, and SSO runs fine without SAML.

What happens when an employee connects

1. The user hits connect in the VPN client.
2. A browser window opens, and the gateway points it at the IdP.
3. Credentials and the second factor get checked there, not on the VPN side.
4. Back comes a signed XML assertion from the IdP: identity, login time, validity conditions, attributes such as email and group membership.
5. With the certificate exchanged during setup, the gateway verifies the signature, applies the group policy and brings the tunnel up.

A first attempt usually fails because the certificate on the gateway does not match the one the identity provider signs with, or because of clock drift.

SAML 2.0 or OIDC

Both carry identity fine. SAML survives because enterprise gateways have spoken it for years; OIDC is lighter for native apps and usually needs fewer fields to configure.

What the company gets out of it

Offboarding turns into a single switch. Disable the IdP account and new VPN sign-ins stop immediately. In a typical VPN setup the sign-in protocol only acts at login and does not report a later removal to the gateway, so an already open tunnel lasts until its timeout. Short sessions or SCIM close that gap.

MFA gets enforced centrally. The IdP applies the second factor and conditional rules (managed device, country) to every app, VPN included, so there is no separate token system to babysit.

SCIM (System for Cross-domain Identity Management, version 2.0, a REST and JSON API from IETF RFC 7643 and 7644) handles the bookkeeping. The provider pushes creation, group changes and deactivation to the VPN on its own, so a leaver's profile no longer lingers in the user list until an admin deletes it by hand. Keep at most one break-glass admin created locally in the VPN: local accounts bypass central MFA and offboarding entirely.

Where ZTNA comes in

Zero trust access grants applications one by one, and identity drives the decision. IdP groups become per-app policies: finance reaches billing, engineers reach the build servers. A stolen IdP session, though, passes ZTNA checks as convincingly as a real one. The VPNRadarLab glossary entry on ZTNA covers that model in depth.

Checks before you buy

• Find out which plan actually includes SAML. Vendors often keep it, or SCIM, on a higher and more expensive tier than the entry plan: Cisco Secure Client lists SAML for the Premier and VPN Only licences and omits it from Advantage; Secomea offers SSO and SCIM from the Professional plan up; remote.it adds SAML from the Business plan. This is the classic "SSO tax", so compare products that confirm SSO support before signing anything.
• Ask about SCIM availability and its plan, if any. Of the 377 services in the VPNRadarLab main ranking, 5 confirm SSO or SAML, 372 do not mention it, and not one mentions SCIM provisioning.
• Look at the session limit and whether re-authentication can be forced.
• Confirm your exact IdP is supported; a generic claim about SAML says little about your setup.

For home users the topic is irrelevant: consumer VPN apps sign in with an email account, and no company directory exists to federate.

FAQ

Can SSO work without SAML?

Yes. OIDC delivers the same outcome, and plenty of modern tools ship only that.

Is SCIM part of SAML?

No. It is a separate accounts API used alongside either sign-in protocol.

Do home VPN users need SSO?

Rarely. SSO and SAML matter for teams with an identity provider, not for a personal subscription.

Short answer

SSO is one company login for the VPN and every other work app; SAML 2.0 or OIDC carries it from Okta, Entra ID or Google Workspace to the gateway. The company gains instant cut-off for leavers, MFA in one place and, with SCIM, accounts that clean themselves up. Verify the tier that includes SAML and SCIM before you pay.