Claude/ChatGPT Prompt to Build Spring Security JWT with Refresh Tokens

What this prompt does

This prompt makes the model configure Spring Security 6 JWT authentication with refresh-token rotation, returning working config and controllers rather than disconnected snippets. It covers the detail most tutorials skip: rotating the refresh token on every use and revoking tokens on logout, so a stolen long-lived refresh token can't quietly keep a hijacked session alive. The filter chain, endpoints, blacklist, and CORS arrive as a connected set you can run, not isolated examples you have to stitch.

The [app_profile] variable sets the app and Spring version so the filter-chain syntax matches. [access_ttl] and [refresh_ttl] define the lifetimes of the access and refresh tokens, which shapes the rotation and expiry logic. [token_store] is where revoked tokens are tracked — the blacklist backing store — and influences how logout revocation and cleanup of expired entries are implemented. Together these produce a stateless filter chain, login/refresh/logout endpoints, role-based method security, and CORS for your frontend origin.

When to use it

• Building a stateless JWT-authenticated Spring Boot 3 API and wanting rotation done right.
• Adding a /refresh flow that invalidates the old refresh token on each use.
• Implementing real logout revocation rather than treating it as optional.
• Locking down endpoints with role-based @PreAuthorize method security.
• Configuring CORS correctly for a separate frontend origin.
• Choosing a blacklist store that can expire revoked entries automatically.

Example output

You get the SecurityConfig, the auth controller, the JWT service, and the blacklist component. The filter chain runs stateless sessions with JWT validation and separates public from protected routes. The controller exposes /login to issue a token pair, /refresh to rotate, and /logout to revoke, with the blacklist backed by [token_store] and cleanup of expired entries. Role-based @PreAuthorize and CORS for the frontend origin complete it. It's a connected set of components built around the [access_ttl] and [refresh_ttl] you specify, not isolated examples, and the pieces reference each other the way they would in a real service.

Pro tips

• Rotate on every refresh — invalidating the old token each time is what limits the damage from a leaked refresh token.
• Store only token IDs in the blacklist, never the raw tokens, so the revocation store doesn't become a secret to leak.
• Set [access_ttl] short and [refresh_ttl] longer; the short access lifetime limits exposure while refresh keeps users logged in.
• Pick [token_store] with cleanup in mind — something like Redis with TTLs lets expired blacklist entries age out automatically.
• Match [app_profile] to your exact Spring Security version so the filter-chain configuration uses the current, non-deprecated API.
• Treat /logout revocation as non-negotiable; without it a token stays valid until natural expiry no matter what the user does.