spring-cloud / spring-cloud/spring-cloud-gateway
302 Redirect vs. 401 Unauthorized on XHR Requests
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 4.9k
- Forks
- 3.5k
- Avg merge
- 20h 57m
- Merged PRs (30d)
- 8
Description
Describe the bug
Context:
We are utilizing Spring Cloud Gateway in conjunction with Spring Boot OAuth2 and Spring Session (Redis). To propagate the Access Token to downstream services, we are leveraging the TokenRelay filter.
On the frontend, we have an Angular application that sends REST (XHR) requests through the gateway. The frontend does not receive access tokens directly; instead, session management is handled through a session ID managed by Spring Session. When a request is made by an unauthenticated user (i.e., without a valid session), the gateway correctly responds with a 401 Unauthorized, as the application cannot process authentication redirects in this context.
Issue:
However, we are experiencing inconsistent behavior when the session ID remains valid but the access token expires. Instead of receiving a 401 or another appropriate 40x response, XHR requests are met with a 302 redirect. As a result, the frontend cannot properly handle the redirect since it expects a 40x error code.
Upon investigating, it appears this issue is related to the OAuth2AuthorizationRequestRedirectWebFilter. When the TokenRelayGatewayFilter attempts to authorize a request and fails due to an expired token, the OAuth2AuthorizationRequestRedirectWebFilter catches the resulting ClientAuthorizationRequiredException and immediately triggers a redirect to the authorization endpoint—regardless of whether the client (the XHR sender) is able to handle redirects.
What's puzzling is that in other components, such as AuthenticationWebFilter, matchers are used to determine whether a redirect is appropriate. From my perspective, it seems like a bug, as the current behavior does not account for API/XHR clients that cannot follow redirects.
Environment:
- Spring Cloud version: 2025.0.0
- Spring Boot Starter OAuth2 version: 3.5.4
Could you please review this situation and let us know if there is a configuration that we may have missed, or if this is a known bug or limitation in the current Spring Cloud Gateway? Ideally, we would expect an appropriate 40x error code to be returned to XHR clients when the token has expired, rather than a redirect.
Sample
I provided a sampe application to reproduce the problem. The basic steps are outlined in the README.
spring-cloud-oauth-redirect-bug-project.zip
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the supplied sample application's README and reproduce the expired-token XHR flow. Then inspect OAuth2AuthorizationRequestRedirectWebFilter, TokenRelayGatewayFilter, and AuthenticationWebFilter to determine why the request becomes a 302 and what configuration or behavior should produce an appropriate 40x response for API clients.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- angular, java, spring, spring-boot
- Domain
- api, authentication, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100