Does VPN SSO sign users in to internal apps automatically?

A VPN gateway that authenticates through an identity provider proves one thing: the provider vouched for a user to the gateway. It does not hand that user a credential for the intranet wiki, the monitoring dashboard or the build server. Those services sign people in through their own federation and apply their own authorisation, and the tunnel only decides which packets can reach them.

Three sessions, three separate decisions

Keep the states apart, because each expires on its own schedule. The VPN session is the gateway's acceptance of an identity plus the network access it granted. The identity-provider browser session is whatever the browser still holds for that provider and may reuse under its policy. The application session belongs to one service that validated a response addressed to it.

Confusing those states produces the wrong question, usually phrased as why the tunnel does not log the user in everywhere. Rephrase it: which application has no federation entry, which one refuses the user, and which one is missing a route. A single sign-in prompt that opens the intranet application can still bounce to the provider, because the second redirect is a new authorisation request for a different audience.

Wire the gateway as its own application

Register the VPN as an approved application in the provider, with its own identifier, redirect URI and user assignment. Then decide which network authorisations that login grants, since that is a VPN policy rather than a provider feature. Users who should reach only the monitoring subnet get a different gateway policy, not a different password.

The tunnel's authentication response is not a reusable credential. OIDC ID tokens carry an audience claim naming the client they were minted for, and SAML bearer assertions restrict the audience to the receiving service provider. A second service that accepts the first service's response is misconfigured, and copying a token into another app is not integration.

Register each internal app, then set the browser context

Each service needs the supported SAML or OIDC values: issuer, client identifier, callback or assertion-consumer URL, required claims and assignment. Reachability comes on top, because identity checks never supply a route or a DNS answer.

1. Create the application entry and confirm the entity or client ID matches what the app sends.
2. Register the exact callback URL including scheme and port; a near miss fails after the user authenticates.
3. Assign the users or groups, then confirm the required claims are released.
4. Allow the identity-provider endpoints as well as the private app, or the redirect cannot complete.

Browser context decides whether an existing provider session is reused. A native client that opens the system browser can share that state, while an embedded view with its own cookie jar usually cannot. New-browser, private windows and a second profile all start from nothing, which is expected rather than a broken SSO configuration.

Run the flow and read where it stops

Reproduce with the browser's network panel and watch the redirect chain. A useful pass follows one hop at a time: gateway to provider, provider back to the app with a code or assertion, app to provider token endpoint, app session issued. The hop where the chain stops names the component to fix.

Two command-line checks settle the usual doubts, and both are safe to run from an admin host:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

When the metadata lists endpoints you never registered, the app is pointing at a different tenant or issuer. When the first request to the app answers 302 to an unexpected host, the application's federation configuration is the place to look, not the VPN profile.

Fix prompts by finding who asked

A second password prompt is not automatically a defect. The application may request a higher assurance level, or the provider may enforce a maximum session age and a fresh challenge. Removing those requirements to make the flow quieter weakens a deliberate control, so establish which component asked before changing policy.

Then decide what to improve. If the prompt comes from the app, fix its federation entry. If it comes from the provider by policy, document the requirement. If the app is unreachable after a successful sign-in, the tunnel routing is the suspect, because identity and packet delivery fail in different places and look similar from the user's seat.