Securing your application
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.
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.
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.
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.
This authentication mechanism doesn’t exist by default with Spring Security, it’s a JHipster-specific integration of the Java JWT project. 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 secure token that holds the user’s login name and authorities. As the token is signed, it cannot be altered by a user.
The secret key should be configured in the
application.yml file, as the
OAuth2 is a stateless security mechanism, like JWT. Spring Security provides an OAuth2 implementation, which is configured by JHipster.
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. JHipster generates the OAuth2 implementation for MongoDB, as well as the necessary MongoDB configuration.
This solution uses a secret key, which should be configured in the
application-*.yml files, using the
jhipster.security.authentication.oauth properties. See the the common application properties documentation for more information on this configuration.