Introduction

When Spring Security generates an OAuth redirect_uri with http instead of https, the usual problem is not OAuth. It is that TLS was terminated by a reverse proxy or load balancer, and Spring never learned that the original public request was HTTPS.

Why the wrong scheme appears

Spring Security builds the redirect URI from the application's perceived base URL. A common default looks like this:

{baseUrl}/login/oauth2/code/{registrationId}

If the request reaches the application as http://internal-host:8080, then Spring computes baseUrl from that internal request unless forwarded headers are applied correctly.

That is why this architecture often breaks:

• browser connects to https://app.example.com
• load balancer terminates TLS
• proxy forwards to Spring over internal plain HTTP

Without forwarded-header support, Spring believes the request is HTTP and emits an HTTP callback.

Forward the public scheme into Spring

In Spring Boot, the normal fix is to let the framework consume forwarded headers:

server.forward-headers-strategy=framework

Your proxy or ingress must also send the right headers. With NGINX, for example:

proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port 443;

Once those headers are present and Spring processes them, the computed base URL becomes the public HTTPS address rather than the internal HTTP hop.

If you need filter-based support on the Servlet side, ForwardedHeaderFilter is another option:

1import org.springframework.context.annotation.Bean;
2import org.springframework.web.filter.ForwardedHeaderFilter;
3
4@Bean
5ForwardedHeaderFilter forwardedHeaderFilter() {
6    return new ForwardedHeaderFilter();
7}

Configure an explicit redirect URI only when necessary

Sometimes you do not want Spring to infer the redirect URI at all. In that case, set it directly:

spring.security.oauth2.client.registration.google.redirect-uri=https://app.example.com/login/oauth2/code/google

This can help in unusual deployments, but it still needs to match the provider registration exactly.

For local development, plain HTTP may be acceptable if the provider allows it:

spring.security.oauth2.client.registration.google.redirect-uri=http://localhost:8080/login/oauth2/code/google

That is a local exception, not the production pattern you should optimize for.

Even when you set the redirect URI explicitly, it is still worth fixing forwarded-header handling. The same proxy misconfiguration that breaks OAuth callbacks can also affect generated links, cookie security, and request-aware application logic elsewhere in the app.

Debug the full request chain

When troubleshooting, inspect all four layers together:

• the public browser URL
• the proxy headers
• Spring Boot forwarded-header handling
• the redirect URI registered with the OAuth provider

One quick debugging endpoint can reveal whether Spring still thinks the request is HTTP:

1import jakarta.servlet.http.HttpServletRequest;
2import org.springframework.web.bind.annotation.GetMapping;
3import org.springframework.web.bind.annotation.RestController;
4
5@RestController
6class DebugController {
7
8    @GetMapping("/debug/forwarded")
9    String debug(HttpServletRequest request) {
10        return "scheme=" + request.getScheme()
11            + ", x-forwarded-proto=" + request.getHeader("X-Forwarded-Proto");
12    }
13}

If request.getScheme() still reports http, the forwarded headers are either missing or not being processed by Spring.

Common Pitfalls

• Changing the OAuth client registration while leaving the reverse proxy headers misconfigured.
• Registering an HTTPS callback with the provider while Spring still emits an HTTP redirect URI.
• Forcing an explicit HTTPS redirect URI without fixing the broader proxy and cookie configuration.
• Assuming local localhost behavior should be copied into production.
• Debugging only Spring configuration and not verifying what headers the proxy actually forwards.

Summary

• Spring usually emits an HTTP redirect_uri because it sees the internal post-proxy request as HTTP.
• Configure proxy headers and forwarded-header support so Spring reconstructs the public HTTPS URL.
• Use an explicit redirect URI only when automatic inference is not appropriate.
• Plain HTTP is usually only reasonable for controlled local development.
• When debugging, verify the browser URL, proxy headers, Spring configuration, and provider registration together.