JHipster generated RBAC least-privilege and credential expiration diagnosis

The JHipster generated backend does not provide default checks for expired credentials or password age. The scaffolded User entity lacks the necessary timestamp fields (such as passwordChangedDate) required to calculate credential age or enforce rotation policies.

Credential Lifecycle and Token Invalidation

The mechanism for handling credential changes depends entirely on the authentication type selected during generation:

• JWT (Stateless): The backend is stateless by default. Because the server does not track active tokens, a JWT remains valid until its expiration timestamp, even if the user's password is changed in the database. There is no default revocation list or "blacklist" in the scaffold.
• OAuth2/OIDC: The JHipster backend acts as a Resource Server. Credential lifecycle, password expiration, and token invalidation are delegated to the external Identity Provider (IdP). The backend simply validates the token's signature and expiration.

Implementing Expiration Checks

To add credential age checks, you must manually extend the scaffold:

1. Add a Instant passwordChangedAt field to the User entity.
2. Create a custom AuthenticationProvider or a OncePerRequestFilter to compare the current date against this timestamp.
3. Throw a custom AccessDeniedException or a specific 401 error when the threshold is exceeded.

Least Privilege Enforcement Scope

In a default JHipster generation, least privilege enforcement is primarily applied at the web layer. This is achieved through SecurityConfiguration.java (URL-based security) and @PreAuthorize annotations on Controller methods.

While the scaffold supports method-level security, it does not automatically apply it to the service layer. For a true least-privilege architecture, you should manually move or duplicate @PreAuthorize annotations to the service layer to ensure that internal method calls—not just HTTP requests—are authorized.

Verification Steps

To verify the current state of your scaffold, run these checks:

• Entity Audit: Check User.java for any fields tracking password age.
• JWT Persistence: Generate a JWT, change the user's password via the API, and attempt to use the original JWT. It will likely still be accepted.
• Security Scope: Check if @PreAuthorize is present in your Service classes; if only present in Resource classes, enforcement is web-layer only.

Missing Diagnostic Detail: Are you using a custom JDL (JHipster Domain Language) to define granular authorities, or are you relying on the default ROLE_USER and ROLE_ADMIN roles?