Security

Securing your application

To use Spring Security with a Single Web Page Application, like the ones generated by JHipster, you need Ajax login/logout/error views. We have configured Spring Security in order to use those views correctly, and we generate all the JavaScript and HTML code for you.

By default, JHipster comes with 2 different users:

• "user", who is a normal user with "ROLE_USER" authorization. The default password is "user"
• "admin", who is an admin user with "ROLE_USER" and "ROLE_ADMIN" authorizations. The default password is "admin"

The two authorizations "ROLE_USER" and "ROLE_ADMIN" provide the same access to the entities which means that a "user" is authorized to perform the same CRUD operations as an "admin". This behavior can be an issue when the application will go to production because a "user" can for example delete any entities. More details on how to improve the access-control can be found on this blog post.

For security reasons, you should change those default passwords in production.

JHipster provides 4 main security mechanisms:

1. JSON Web Tokens (JWT)
2. Session-based authentication
3. OAuth 2.0 and OpenID Connect

JSON Web Tokens (JWT)

JSON Web Token (JWT) authentication is a stateless security mechanism, so it's a good option if you want to scale your application on several different servers.

Please note that this is the default option when using a [microservices architecture]({{ site.url }}/microservices-architecture/).

This authentication mechanism doesn't exist by default with Spring Security, it's a JHipster-specific integration of the Java JWT project.

This solution uses a secure token that holds the user's login name and authorities. As the token is signed, it cannot be altered by a user.

Securing JWT

• JHipster uses a secret key, which can be configured using two Spring Boot properties: jhipster.security.authentication.jwt.secret and jhipster.security.authentication.jwt.base64-secret. The second option uses a Base64-encoded string, so it is considered more secured and thus it is recommended. If both properties are configured, the secret property (less secured) will be used, for legacy reasons. A warning will be shown at application startup if you don't use the Base64 property.
• Those keys should have a minimum length of 512 bits: if they are not long enough, you will not be able to use them to login. If that happens, there will be a clear warning at the console to explain that issue.
• The secret keys are configured in the application-*.yml files. As those keys must be kept secret, you should store them in a secure way for your production profile. It can be set up using the usual Spring Boot property configuration: using a Spring Cloud Config server like the [JHipster Registry]({{ site.url }}/jhipster-registry/) (our recommended option), using an environment variable, or even a specific application-prod.yml file which is SCP'd by a sysadmin into the same directory as your application's executable WAR file.
• You should change the default "user" and "admin" passwords. The easiest way to do this is to deploy your application, login as "user/user" and then "admin/admin", and for each of them use the "Account > Password" menu to change the password.

Session-based authentication

This is the "classical" Spring Security authentication mechanism, but we have improved it quite significantly. It uses the HTTP Session, so it is a stateful mechanism: if you plan to scale your application on multiple servers, you need to have a load balancer with sticky sessions so that each user stays on the same server.

Securing Session-based authentication

• For remember-me authentication, the remember-me key is configured in the application-dev.yml and application-prod.yml files, as the jhipster.security.remember-me.key property. As this key must be kept secret, you should store it in a secure way for your production profile. It can be set up using the usual Spring Boot property configuration: using a Spring Cloud Config server like the [JHipster Registry]({{ site.url }}/jhipster-registry/) (our recommended option), using an environment variable, or even a specific application-prod.yml file which is SCP'd by a sysadmin into the same directory as your application's executable WAR file.
• You should change the default "user" and "admin" passwords. The easiest way to do this is to deploy your application, login as "user/user" and then "admin/admin", and for each of them use the "Account > Password" menu to change the password.

Improved remember-me mechanism

We have modified the Spring Security remember-me mechanism so that you have a unique token, that is stored in your database (SQL or NoSQL database, depending on your choice during generation!). We also store more information than the standard implementation, so you have a better understanding of where those tokens come from: IP address, browser, date... And we generate a complete administration screen, so that you can invalidate sessions, for example if you forgot to log out on another computer.

Cookie theft protection

We have added a very complete cookie theft protection mechanism: we store your security information in a cookie, as well as in the database, and each time a user logs in we modify those values and check if they have been altered. That way, if a someone ever steals your cookie, they will be able to use it only once, at most.