基于Java Spring与PostgreSQL的REST API及Web服务安全架构选型咨询
Hey there, let's work through this based on your setup and concerns—you've got a solid stack with Spring + PostgreSQL, plus a Spring Web server serving up that API to browsers (and soon mobile), and you're right to be cautious about exposing credentials to clients. Let's break down practical, Spring-friendly solutions that hit your requirements:
Since you already have a Spring Web server acting as the client's entry point, this is the cleanest way to keep API credentials far away from frontend code entirely:
Frontend ↔ Spring Web: Secure Session or JWT (No Client-Side Credentials)
- For user-facing auth (if your app requires user logins): Have users authenticate with their own username/password via the Spring Web server. After validation, set an HttpOnly, Secure, SameSite=Strict cookie containing either:
- A session ID: Spring Security handles this out of the box. Use Redis for session sharing if you scale later—browsers auto-send the cookie, and JS can't access it (blocks XSS leaks).
- A short-lived JWT (15-30 mins): Pair it with a longer-lived refresh token (7-30 days) in another HttpOnly cookie. When the access token expires, your frontend can silently call a refresh endpoint to get a new one, no user input needed.
- All frontend requests go through the Spring Web server, which forwards them to your REST API. The frontend never talks directly to the API server—so it never sees API credentials.
Spring Web ↔ REST API: Server-to-Server Auth (Hidden Credentials)
This part stays entirely behind the scenes, with credentials stored securely in your Spring Web server's config:
- OAuth2 Client Credentials Flow: Perfect for machine-to-machine auth. Configure your Spring Web server as an OAuth2 client, and your REST API as a resource server. The client uses a secure client ID/secret (encrypted in your
application.ymlor stored in a secrets manager) to fetch an access token for API calls. - API Key Auth: If OAuth2 feels overkill, generate a unique API key for your Spring Web server. When it calls the REST API, include the key in a request header like
X-API-Key: [your-secure-key]. This key lives only in your backend config—frontend code never touches it.
If skipping the gateway isn't an option, you can fix JWT's common pain points while keeping credentials safe:
- Never store JWT in localStorage/sessionStorage: Always use HttpOnly, Secure, SameSite=Strict cookies. This blocks JS access, eliminating XSS risks.
- Short access tokens + refresh tokens: As mentioned earlier, short-lived access tokens limit damage if leaked. Refresh tokens (also in HttpOnly cookies) let you get new access tokens without re-authenticating the user.
- Token blacklisting: If you need to invalidate tokens early (e.g., user logs out, account is suspended), store revoked token IDs in Redis. Your REST API checks this blacklist before validating any JWT.
- Keep JWT payloads non-sensitive: Payloads are Base64-encoded (not encrypted), so only include safe data like user IDs, roles, and expiry times. Use RS256 asymmetric signing (private key signs tokens, public key validates them) to prevent tampering.
Your concerns are spot-on: Basic Auth requires encoding credentials and storing them in frontend code or request headers, which is trivial to grab via browser dev tools. Plus, those credentials are long-lived—if leaked, an attacker has ongoing access to your API. It's simply not safe for frontend-facing apps.
If you're already running that Spring Web server as the client entry point, go with Option 1—it's the most secure, maintainable approach that completely isolates API credentials from end users and frontend code. If you need direct frontend-to-API calls, the optimized JWT setup will address your worries about credential exposure and JWT's limitations.
内容的提问来源于stack exchange，提问作者Bloodlex
