OAuth inside a VPN: which legs still require TLS

Private routing decides who reaches the server; OAuth transport rules decide how each message travels. A browser, an authorization server, a token endpoint and a resource server can all sit behind the same VPN and still exchange messages over different legs. Each leg has its own transport requirement, and the VPN does not relax any of them. The VPN boundary and the protocol boundary are different lines.

The decision is easier if you stop asking whether the network is trusted and start asking which exchange is crossing which boundary.

Decide by leg, not by network

Write down the endpoints separately: authorization endpoint, token endpoint, redirect URI, resource-server URL, TLS termination point and VPN gateway. Then mark which party originates each request and where the response goes.

A VPN that terminates at a gateway encrypts the segment to that gateway. The request may continue as plain HTTP behind it, and that remaining leg has not become HTTPS because an earlier segment was encrypted. That continuation is the leg the protocol cares about. Encrypting the first hop does not make the second hop secure.

The transport also carries a service-identity check. The browser validates the certificate for the application URL; a VPN does not perform that validation on the browser's behalf, and it does not make an unvalidated endpoint acceptable. The certificate names the endpoint the client believes it is calling. A tunnel to a gateway does not rename that endpoint or validate it.

The authorization response and the redirect URI

OAuth's security best current practice forbids transmitting authorization responses over unencrypted connections. That covers the redirect that carries the authorization code or tokens back to the client, not only the initial request.

The same guidance disallows HTTP redirect URIs except for the specified native-client loopback case. An internal hostname does not create a new exception, and a DNS name that only resolves inside the VPN is still an HTTP URL if the scheme says so. Check the scheme in the registered URI, not only the hostname.

Register the exact HTTPS redirect URI with the authorization server and keep certificate validation enabled on the client. A development shortcut that suppresses the HTTPS requirement produces a flow that behaves differently from the production configuration it is supposed to model.

The token endpoint and bearer-token requests

The token request carries credentials or a code that can be exchanged for access. Sending it over an unprotected leg exposes material that the resource server will later trust, even if the surrounding network is private. A proxy that can read the request can also read the credential it carries.

For bearer-token resource requests, RFC 6750 treats TLS as mandatory to implement and use for that specification. Calling the office subnet trusted is not the general protocol exception a plaintext bearer deployment needs.

Use the documented secure endpoint URLs for both legs. If a library refuses to call an HTTP token endpoint, that refusal is the specification working, not a configuration bug to bypass. Record that URL in the client configuration rather than deriving it at runtime.

Where TLS terminates and what that leaves

If TLS ends at an authorized frontend, name that frontend and review the path from it to the application. The frontend becomes responsible for forwarding, trust and confidentiality on the remaining segment, and the service's supported architecture should describe that arrangement.

A VPN elsewhere in the path does not settle those responsibilities. It also does not tell you whether the application URL the browser sees matches the certificate the frontend presents.

For an internal deployment, record the termination point and the identity it presents. A frontend that terminates TLS with a certificate for a different name creates a browser warning that operators often suppress instead of fixing.

The native loopback exception is narrow

The loopback redirect exception concerns a callback on the user's own device, where the client and the browser share that device. That arrangement belongs to a callback on one device, and it does not license serving a normal authorization server or a token-bearing API over HTTP to an office subnet.

Keep the exception scoped to the client type and the callback it describes. Applying it to a web application, a shared internal service or a redirect URI on another host changes the deployment, not the exception.

Test the actual flow at each boundary and compare it with the client type. A working redirect says nothing about whether every leg that carried a token used the required protection, and a green VPN icon says nothing about the scheme of the next request.