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 of course we generate all the JavaScript and HTML code for you.

By default, JHipster comes with 4 different users:

"system", who is mainly used by our audit logs, when something is done automatically
"anonymousUser", who is given to anonymous users when they do an action
"user", who is a normal user with "ROLE_USER" authorization. His default password is "user"
"admin", who is an admin user with "ROLE_USER" and "ROLE_ADMIN" authorizations. His default password is "admin"

For security reasons, you should change those default passwords.

HTTP Session 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.

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 user ever steals your cookie, he will be able to use only once, at most.

CSRF protection

Spring Security and AngularJS both have CSRF protection out-of-the-box, but unfortunately they don't use the same cookies or HTTP headers! In practice, you have in fact no protection at all for CSRF attacks. Of course, we re-configure both tools so that they correctly work together.

Social Login

JHipster provide "social login", using Spring Social, so users can connect to your application using their Google, Facebook or Twitter authentication. This is configured using Sping Boot's starter modules.

OAuth2 Authentication

OAuth2 is a stateless security mechanism, so you might prefer it if you want to scale your application across several machines. Spring Security provides an OAuth2 implementation, which we have configured for you.

The biggest issue with OAuth2 is that requires to have several database tables in order to store its security tokens. If you are using an SQL database, we provide the necessary Liquibase changlog so that those tables are automatically created for you.

As Spring Security only supports OAuth2 with SQL databases, we have also implemented our own MongoDB version. We generate for you all the OAuth2 implementation for MongoDB, as well as the necessary MongoDB configuration.

This solution uses a secret key, which should be configured in your application.yml file, as the "authentication.oauth.secret" property.

Token-based authentication

Token-based authentication, like OAuth2, is a stateless security mechanism, so it's another good option if you want to scale on several different servers.

This authentication mechanism doesn't exist by default with Spring Security, so it's specific to JHipster. It is easier to use and implement than OAuth2, as it does not require a persistence mechanism, so it works on all SQL and NoSQL options.

This solution uses a custom token, which is a MD5 hash of your user name, the expiration date of the token, your password, and a secret key. This ensures that if someone steals your token, he should not be able to extract your username and password.

The secret key should be configured in your application.yml file, as the "authentication.xauth.secret" property.