The new Certification Class of Learn Spring Security is out:


Building a full-fledged, production ready registration for your web application is oh so much more than just putting together a simple registration page.

There are a lot of questions that need to be answered:

  • How do I verify the email addresses of new users?
  • How do I properly and safely store user credentials?
  • What if a user forgets their password?
  • What about users changing their own password?
  • How strong should passwords be? How can I enforce some sensible defaults in the app so that my users have good, strong passwords?
  • What if I have more than one type of user? I need a good way to store roles and privileges.
  • What about security questions? Should I even have them?
  • How do I do all of this with good localization support? There are a lot of messages involved.

>> The Registration Process

Starting at the top – this is how to set up a basic Registration process for your web app. Doesn’t have to many bells and whistles, but it’s clean and functional to begin with.

>> Activate a New Account by Email

Now we want to make sure that users verify their emails before being able to just log into the app.

>> Resend the Verification Email

If a user signs up and doesn’t verify their email for a while – their verifications expires at some point. This is how they request a new verification link.

>> Registration – Password Encoding

The age old question – how to store passwords? Simple answer? You don’t!

>> The Registration API becomes RESTful

Making the Registration API more RESTful and adapting the front-end to correctly consume it.

>> Reset Your Password

Users are forgetful creatures – so they’ll forget their passwords sooner rather than later. You should have a good way for your users to reset their passwords if they need to.

>> Password Strength and Rules

Making sure your users use good, strong passwords is super important. The registration process should guide them towards good password etiquette.

>> Updating your Password

How to enable the user to update/change their own password after logging into the app.

Go deeper into Spring Security with the course:


  • Hasan

    Hi Eugen,

    Are you planning to make same tutorial by using Angular js ?

    • Hey Hasan – I am considering doing that, but it’s a lot of work so I haven’t decided yet 🙂
      Thanks for the suggestion though. Cheers,

      • Hasan

        Thanks, nowadays I try to use angular js in my project instead of spring mvc… As I see some methods in your “The Intermediate Class” course,now I want to use Angular js but I’m hardening to apply it in my project. I need single page application using by Angular js… If you make a tutorials like this one, it would be great :)))) Best Regards

        • Hey Hasan,
          One quick nuance I wanted to bring up here, is that I don’t see this as either Spring MVC or AngularJS. Even if, in this context, we’re saying JSP or some other templating library when we say “Spring MVC” – you can still use both just fine.
          I’ll keep writing about the topic of course – there’s some interesting stuff in the content calendar of the site. Cheers,

          • Hasan

            Actually I tried to say, if you make an example single page application using Angular js in next couple of days, it would be great for your followers 🙂 thanks for whole good tutorials… Best Regards

          • Hey Hasan – the content calendar of the site is scheduled for many months, so the timelines for something like that is definitely not a couple of days.
            Plus, as I was saying before, it’s not something I decided on yet.
            Thanks for the feedback. Cheers,

  • Rubén Pahíno Verdugo

    Hi again Eugen,

    I think this whole registration part is awesome!! I’m wondering, if I start from the resultant project after following the entire guide, what else do I have to do to have a production ready registration service? Any guide/book/article you can recommend me? (Also I want to know how “ready” can it be as it is for production).
    Also in the github code I noticed that when you handle the reset password request you don’t validate the new one, being able to submit weaker passwords. Is it because you didn’t realize? or is it because if users decide to do so, it’s their problem?
    The last one… could it be right to implement the registration controller “100% restful”? With that I mean to design the controller methods to recieve @RequestBody objects via POST (“/user/registration” for example).

    Thank you very much,


    • Glad you’re putting the project to good use 🙂
      Let me answer your question with the good ol` “it depends”. It really does depend on what you’re trying to achieve. Beyond things like password storage practices, CSRF, etc – it’s also what features you need around your registration scenarios.
      Yeah, the second password validation is just missing in the example, but should definitely be there for a production system.
      Finally – yes, you can definitely implement registration in a more RESTful manner.
      So, the way I would look at the project is – a great way to start, but you still need to understand everything and improve things here and there.
      Hope that answers your questions. Cheers,

      • Rubén Pahíno Verdugo

        That answers my questions but I would like you to recommend me some material to go deeper (if you know). Also, another important doubt comes to me: Is it a good practice to decouple the registration service from the authorization one? I’m thinking of having one isolated registration server as this one (but production ready), with the capability of modifying the profile information, and one OAuth2/OpenId connect server, so the registration server can be securized via OAuth2 too, but don’t know if makes sense to decouple them or if it’s better to keep them as one only (or if neither of them make any sense).Any light on this topic would be extremely helpful.

        Thank you very much,


        • Hey Ruben – there isn’t a whole lot of material on the topic of registration out there (that I’m aware of).
          As for the responsibilities – you can start with them together and only segregate them if you need to further down. Regardless of how you do that, you definitely do need to secure that as well (the non-public operations that is). Of course that doesn’t mean you need to run them together, but it’s simpler if you do.

          • Rubén Pahíno Verdugo

            Well, the idea why I was thinking of starting with them separated was that I saw projects like MitreID that offer the starting point to an OpenId Connect Identity provider, so I thought of just don’t mix things. Even though I’ll start with everything together and I’ll begin to separate while I go deeper (if needed).


          • Rubén Pahíno Verdugo

            Sorry to question again Eugen.
            At this point I refactorized lot of things but there are two that come to my mind about the design:
            1) why do yo have all that logic in your controller? isn’t cleaner to have controllers just as entry points with the capability of transforming the domain objects if needed and all the logic on the service layer? It isn’t a complain, is just curiosity because I’m wondering if there is a major reason
            2) what advantage do you see on having specific @ComponentScan annotations on every Spring configuration class instead of a global @ComponentScan on the that scans the whole structure? As a disadvanage I see that it “forces” you to separate your packages by layer instead of by function (token, user, etc), wich is less intuitive (for me) and also makes you open your classes, interfaces and methods scopes, making everything to be public.

            Thank you,

          • Hey Ruben – no worries about following up with extra questions – that’s what the comments are for 🙂
            1. Yes, it would be cleaner. The first reason is that the project was iteratively developed to illustrate some implementation points, not as a production ready codebase, so there wasn’t a lot of cleanup after each scenario.
            Also keep in mind that these are MVC style controllers, so sometimes you can’t really go as clean as you would with a REST-style controller. For example, if – based on some condition – the controller needs to redirect – then that’s a concern that does belong in that layer.

            2. That’s an interesting question.
            It’s mostly for testing – I like to make sure that each configuration deals with and is able to pull in the layer / part of the system that it’s relevant to. That will allow you to write very clean, focus integration tests rather than having to bootstrap the entire context for everything.
            For example, if you’re testing a repository, that test doesn’t need to bootstrap the service or controller layer – just low level persistence.
            You can go of course with a functional delimitation as well. However, within that functional delimitation, I’d still go horizontal as well – to be able to bootstrap the parts that I care about in a test.
            But in the case of this simple system – that would be to much.
            Hope that clears things up.

          • Rubén Pahíno Verdugo

            Thank you for answering. I found an article/video (not sure) where you explain that way of separating the contexts. I just forgot to modify the comment. Given that approach I agree with you, I’m sure it’s worth it that need of opening the scopes for making much conciser tests.



          • Sound good Rubén. Cheers,