I just announced the newSpring Security 5 modules (primarily focused on OAuth2) in the course:
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.
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,
Eugen.
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,
Eugen.
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,
Eugen.
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… Read more »
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… Read more »
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… Read more »
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.
Cheers,
Eugen.
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).
Thanks,
Rubén
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… Read more »
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… Read more »
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.
Cheers,
Rubén.
Sound good Rubén. Cheers,
Eugen.