Securing a JHipster App with Built-in JWT Authentication

The Problem: Hand-Rolled Token Login Delays Delivery

Adding secure, token-based login to a Spring Boot application means writing custom security filters, token issuance, validation logic, and frontend code to attach credentials to every request. That plumbing delays feature work and can introduce security mistakes if done by hand.

The Takeaway: Let JHipster Generate JWT Security

JHipster 7.x and later includes built-in JWT authentication. A JSON Web Token (JWT) is a stateless, signed token that carries user identity; the server verifies it on each request without storing session data. When you generate a new application and choose JWT, JHipster creates the security configuration, DTOs, and client stubs automatically.

Confirm JHipster 7.x or Newer

Run this command in your terminal:

jhipster --version

Required permissions: none. This is a read-only check. Expected output: a version number starting with 7 or higher. If the command is not found, install JHipster first. Risk: none.

Generate a JWT-Enabled Application

In an empty directory, run:

jhipster

When prompted for authentication, select JWT. The generator writes files to the current directory, so this changes filesystem state. Rollback: delete the generated directory or restore from version control before committing.

JHipster writes security.yml under src/main/resources/config/ for Maven projects, or the equivalent resource folder for Gradle. It also generates a React login page and an HTTP interceptor that attaches the token to API calls. An interceptor is client-side code that runs before each outgoing request to modify headers.

Configure Token Lifetime in security.yml

Open security.yml and locate the jwt block:

jwt:
  secret: &jwtSecret
    - base64: &jwtSecretBase64
  token-validity-in-ms: 604800000

token-validity-in-ms sets how long the JWT remains valid, in milliseconds. The example above is 7 days. Change it to match your security policy, for example 3600000 for one hour. A shorter validity reduces the window for a stolen token but requires users to log in more often.

Save the file and restart the application. To revert, change the value back and restart again. Risk: do not commit the actual secret value to version control; use an environment variable or secret manager in production.

Watch the React Client Attach the Bearer Token

After a user logs in, the generated React client calls /api/authenticate and receives a JWT. It stores the token in memory and attaches it to subsequent requests using an HTTP interceptor with the header:

Authorization: Bearer <token_value>

A bearer token is the value sent after the word Bearer in the Authorization header. The Spring Boot back end validates the signature and expiry using the secret key in security.yml. If you enable CORS, confirm that the Authorization header is allowed in your CORS configuration, otherwise the browser will block the request.

Limitation: Stateless Tokens Are Difficult to Revoke

Because JWTs are stateless, the server does not track them after issuance. Immediate revocation—for example, after a user logs out or a token is stolen—requires a separate blacklist or short expiry combined with refresh tokens. Adding a blacklist reintroduces server-side state, which reduces the simplicity of stateless authentication.

Verify the Token Flow

1. Start the application from the project root: ./mvnw for Maven or ./gradlew for Gradle.
2. Open the generated login page in a browser, sign in, and use browser developer tools to confirm the response from /api/authenticate contains a token.
3. Call a protected endpoint with curl, replacing <token> with the observed value:

curl -i -H "Authorization: Bearer <token>" http://localhost:8080/api/sample

Expected check: a 200 OK response. If you receive 401 Unauthorized, the token is missing, expired, or the header is malformed.

1. Temporarily set token-validity-in-ms to 60000 (one minute), restart, log in again, and wait more than one minute before repeating the curl call. Expected check: 401 Unauthorized after expiry.

Limitation: the generated client stores the JWT in memory by default, so a page reload clears it. Add persistent storage or a refresh-token flow if users must remain logged in across reloads.

Next Step

Run the JHipster generator, select JWT authentication, set token-validity-in-ms in security.yml to match your policy, and verify the bearer token flow with the curl check above before deploying.