The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →For a React application backed by Spring Boot, choose who handles the OAuth2 login before writing authentication code. The browser can act as a public client and call a Spring resource server with an access token, or Spring can handle the provider login and serve React through a session-based backend-for-frontend (BFF). Neither pattern is universally best: the identity provider, hosting layout, browser credential transport, and need to call provider APIs all affect the design.
React is a UI library, not an authentication protocol. Spring Security provides building blocks for OAuth2 login, OAuth2 clients, and protected resource servers; the application still has to define its trust boundaries, authorization rules, and browser behavior.
As an Amazon Associate I earn from qualifying purchases.
Understand the actors and trust boundaries
A typical flow involves five parts: the user agent (browser), the React interface, the Spring Boot application, an authorization server or identity provider, and the protected API. Depending on deployment, Spring Boot may provide both the OAuth2 login client and the API, or a separate service may host the API.
- React: renders screens and initiates user actions. Code delivered to the browser is visible to its user and cannot keep a client secret confidential.
- Spring Security OAuth2 Client: can handle a redirect-based login flow and maintain the resulting server-side authentication.
- Spring Security Resource Server: validates bearer access tokens presented to an API. The framework documentation notes that this can support bearer tokens including custom JWTs.
- Authorization server or identity provider: authenticates the user and issues OAuth2 tokens. OpenID Connect (OIDC) adds an identity layer commonly used to establish who signed in.
- Application authorization: decides which operations and records an authenticated identity may access. A valid login or token does not make that decision by itself.
OAuth2 is an authorization framework; OIDC is an identity protocol built on OAuth2. Be precise about whether a token is being used to authorize API access or whether OIDC claims are being used to establish a signed-in user. A JWT is not encrypted by default: signature validation can establish that its contents have not been altered, but it does not make those contents secret.
#1 Best Overall
Choose where the browser credential lives
Two common designs fit this stack. In the direct SPA pattern, React is a public OAuth2 client and sends an access token to the API. In a BFF pattern, Spring handles provider login and the browser talks to Spring using a session cookie; provider tokens remain on the server. These are architectural choices, not a framework rule that one must always be used.
| Decision | Direct React client | Spring login with BFF |
|---|---|---|
| Provider login | React participates in Authorization Code with PKCE. | Spring Security OAuth2 Login redirects the browser and handles the provider callback. |
| Browser credential | An access token is available to browser code when React calls the API. Decide deliberately how the client obtains and handles it. | The browser uses a session cookie to reach the application; provider tokens can be kept server-side. |
| API call path | The browser calls the Spring resource server with a bearer token. | The browser calls the Spring application, which acts as the intermediary for application requests. |
| Key security work | Protect token handling, validate tokens and API permissions, and configure cross-origin access if deployment requires it. | Protect cookie-authenticated unsafe requests against CSRF, set cookie behavior to fit the deployment, and secure the server-side session and tokens. |
| Provider API access | Useful when the browser itself needs provider-authorized API access, subject to provider scopes and client support. | Useful when the backend should hold provider tokens and make provider API calls server-to-server. |
| Operational considerations | Requires public-client registration, PKCE, browser token handling, and API resource-server validation. | Requires server-side OAuth client and session operations, cookie and CSRF decisions, and a browser-to-backend request path. |
A BFF is a pattern, not a reason to assume every browser OAuth recommendation is a finalized standard. Select it when its server-side token handling and request path suit the product, and verify applicable guidance for the identity provider and deployment.
Pattern A: React uses Authorization Code with PKCE
Register React as a public client
A browser-delivered application cannot protect a client secret. Do not put one in React source, build-time environment variables that are compiled into the bundle, or browser network requests. Register the SPA as a public client with the identity provider and use Authorization Code with PKCE. Spring Security’s grant documentation describes PKCE support for public clients; Spring Authorization Server also documents an SPA PKCE setup.
At a conceptual level, the browser starts authorization with a code challenge, the user authenticates at the provider, and the provider returns an authorization code through the browser. The client then redeems the code using the matching verifier. The redirect flow is not a plain REST login call. Configure the exact redirect URI in both the client and provider registration; a mismatch commonly prevents the provider from returning to the application.
Protect the API as a resource server
Configure the Spring API to accept bearer access tokens as a resource server rather than treating any decoded token as trusted. The Spring Security JWT reference describes issuer metadata and JWK discovery for signature validation. It identifies spring-security-oauth2-resource-server and spring-security-oauth2-jose as the relevant modules for JWT bearer-token decoding and verification. The reference consulted reports Spring Security 7.1.1; check the documentation and dependency compatibility for the Spring Boot and Spring Security versions actually used by the application before adopting configuration syntax.
Issuer validation is not the whole authorization model. Confirm that the token is intended for this API, including the audience requirements established for the identity provider and service. Then define how trusted claims map to application authorities and enforce permissions at the relevant endpoints and data boundaries. Do not assume a provider role or scope automatically means the same thing as an application permission.
Plan browser and API boundaries
If the React origin differs from the API origin, configure CORS for the real frontend origin and only the methods and headers the application needs. Do not use wildcard origins with credentialed requests. CORS is a browser access policy, not a substitute for API authentication or authorization.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Choose CSRF protections based on how credentials are transported and whether the browser attaches them automatically. A bearer token that application code explicitly attaches presents a different CSRF consideration from an automatically sent session cookie; neither observation justifies disabling CSRF protection globally without examining the actual request flow. Browser token handling also needs an explicit threat model, especially for script injection risks.
Pattern B: Spring handles login and React uses a session
Use Spring Security OAuth2 Login for the redirect
With Spring as the OAuth2 client, the browser is redirected to the provider for authentication, then returns through Spring’s callback. Spring Security documents the default servlet redirection endpoint as /login/oauth2/code/*. That callback belongs to the backend; it is not automatically a React route. Register the matching redirect URI with the provider and configure where the user should land after login.
After the callback, Spring can maintain the authenticated state server-side and the browser can make application requests using a session cookie. React needs a clear way to learn whether the session is authenticated, such as an application endpoint that returns the relevant user-facing state. Do not expose provider tokens to the UI merely to display a signed-in screen.
Make cookie, CSRF, and origin behavior explicit
Cookie-backed sessions are convenient for browser requests, but the browser’s automatic cookie behavior makes CSRF protection important for state-changing requests. Keep protections appropriate to the session design and identify which methods change server state. Choose cookie attributes and same-site behavior for the real topology; cross-origin and cross-site deployments have different constraints and may require coordinated frontend, backend, and provider settings.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →When the UI and backend use different origins, permit only the application’s actual origins and required request behavior. Credentialed requests require deliberate CORS configuration, and wildcard origins are not appropriate for that case. CORS and CSRF solve different problems, so configuring one does not remove the need to assess the other.
Best Value
Turn the selected design into a deployment flow
Write down the actual browser redirects and API hops before configuring the application. These two sketches show the distinction; they are architecture diagrams, not provider-specific endpoint configurations.
Direct SPA with bearer-token API calls
Browser / React → Authorization Server (login and PKCE redirect)
Browser / React ← Authorization Server (authorization response)
Browser / React → Spring Resource Server (API request with bearer token)
Spring Resource Server → validates token, then applies application authorizationSpring login with a session-backed BFF
Browser → Spring Security OAuth2 Login → Authorization Server
Browser ← Spring callback and application session
Browser / React → Spring application (session-backed request)
Spring application → protected service or provider API as requiredFor either design, make the following implementation decisions and verify them against the chosen versions and identity provider:
- Versions: record the Spring Boot and Spring Security versions and use matching reference documentation and dependency versions.
- Client and redirect registration: specify the client type, grant, exact redirect URIs, and post-login destination. Ensure the browser client has no confidential secret.
- Token validation: identify the expected issuer, audience, signature keys, and claim mapping. Plan for key rotation and an explicit clock-tolerance policy appropriate to the provider and application.
- Session and failure behavior: decide what the UI displays when login fails, a session expires, or an API request is unauthenticated. Define logout behavior at both the application and provider where relevant; ending a local session and ending an identity-provider session are not necessarily the same action.
- Browser policy: list allowed CORS origins, methods, and headers where needed. For cookie-authenticated state changes, retain an appropriate CSRF defense. Test the actual same-site or cross-origin arrangement rather than assuming a local development setup matches production.
- Operations: keep server-side credentials and signing or encryption material in managed secrets rather than source code. Require HTTPS in deployment, decide what authentication events to audit, and avoid logging secrets or complete bearer tokens.
- Authorization tests: test unauthenticated requests, authenticated requests with permitted access, and authenticated requests that must be denied. Include representative record-level rules, not only a successful login test.
Keep identity separate from permission
Authentication answers who signed in; authorization answers what that identity can do in this product. Spring Security can validate an OAuth2 access token, but the application must still decide how roles, scopes, or other trusted claims map to its own permissions and whether a user may access a particular record. Keep those rules explicit and test denial paths as carefully as successful access.
The right flow is the one whose trust boundaries match the deployment: direct SPA access when browser-held bearer-token handling is acceptable, or server-handled login when the application benefits from keeping provider tokens behind Spring. In either case, React presents the interface, Spring enforces the backend boundary, and the authorization model remains an application responsibility.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
