User Signup with Email Verification 🔥 Spring Boot + Spring Security

Key Takeaways

Hey everyone, welcome back. As you know in the spring security playlist, we had a video on HTTP basic authentication which was the second video. In HTTP basic authentication, we own the user data. So in the user registration phase, we were storing the users in the table. Then in the authentication phase, we were comparing the username and password. Now in this video we will extend the HTTP basic example. So you might have seen this pattern where we register on a website but initially we are inactive then we get an email to activate ourselves. So we will see in this video how to register a user in inactive state then we will learn how to trigger the email where the user can activate. All right. So in this example in this video we will not cover the actual authentication because that has been covered in the second video HTTP basic authentication. So you can pick the authentication code from this example and implement the end to end flow yourself. All right. So let's get started and understand what we are going to implement and how. [Music] So here on the screen we have a very simple data flow diagram. On the left we have the actor or the user. The user will use a particular endpoint to register itself. Then we will have a controller. From the controller we will go to different services and as part of the services the first thing we will do is to create the user and this part we already covered in the HTTP basic authentication. The additional thing here is to create the unique token for that user. Additionally we will also store the status of the user and token. So initially the user will be in inactive state and the token will also be let's say active state because the user has to activate itself. All right. And once the user activates itself using the token, we can disable the token to avoid reusing the same token. So in the database, we will have two tables. One user and the another one user token because we have to maintain the relationship of the user and the token. So here you can see the table structure as well. This is the users table where we have email, password, status and username and then we will have user token which will only have user ID, status and token. All right. And that leads to the second flow where the user will click the link to activate and that will hit another endpoint where the user will provide the token that will be intercepted by another controller and another service. So here what we will do first we will find the token because we already got the token as part of the request. So first we will find the token and the token has to be active. If the token is inactive that means the user has already consumed that token. All right. So that kind of validations we can do on the basis of token status. That's why we are storing the token status. So if the first step is to find the token then because we are storing the user ID in the user token table. So we can find the corresponding user and then in the end we can activate the token and the user and update the data in the database and in this state I mean we will inactivate the token but activate the user. So the status would be a little bit different for the user and the token and that update will happen in the database. So once the user is active we can implement the authentication part using HTTP basic where we will let's say implement the user details service. The additional check here would be when we are loading the user we will put an additional check of status. So when we are loading the user in the authentication flow we will only load the user which is active. All right. So if the user is inactive it will not find the user and the authentication fail. And that's what we want. We want to authenticate only if the user is active. So that will be the additional change that you will do in the original HTTP basic demo in the authentication flow. All right. So now that we have covered the overall flow, let's start implementing it. Let's start by creating a simple project and then we will enrich it step by step. Now before we jump onto the code, there is one additional step that we have to do because we have to trigger an email. So we need a system from which we can trigger the email. So there is one mail trap system that I am using. So you need to create an account and with the free account you get a lot of emails that we can use. So once you create the account on the Mailch system you will see something like sandbox. You go to the sandbox you create one sandbox to use with the demo. Now once you have the sandbox you will go to the API section and you will create an API token and you need to copy that API token because we will use this token when we create the project to send the email. All right. And here in this section you can see the code example for different languages that you can use. So in our case we will use the Java and you can see the code that we are going to use to send the email. You can also find the additional details on the Java SDK. So if you click on that link it will open the GitHub repo and you can find all the details like what dependency you need to add in the project and what is the code the minimal code that you need to send an email and this is sufficient for the demo. All right. So we are going to use this one. If you choose to go with mail trap then follow the steps otherwise you can find another service that can provide you to send the emails. All right that being said we will go to the spring initializer and we will create a simple project. The next step is to add the dependency. So the first one will be web. We also need to add spring security dependency and in this video we are going to use postgress. So we will add the driver lumbar and that's it. So let's generate the project. All right. So we have the skeleton project. Let's go to the pom.xml to verify the dependencies that we need are already there. So we can see we have spring security, spring starter web, Postgress SQL, the driver, the long, the test. All right, there is one dependency that we missed which is the spring data JPA because we need to read the data from the database. So let me add that one as well and the second one will be the mail trap. So we'll go back to the browser and we will copy this section. All right. So let's add this dependency and reload the project. All right. So the next step is to provide the application.properties file in which we will provide the details of the database. So let me add the application.properties file. We'll go to the main resources. We'll add a new file here application. And I will simply paste the content that I have. So you can see this is the name of the application. This is the database that we are going to use and let me quickly go back to the postgress. And here you can see I have a simple database email verification demo that I will use in this example. And you can see in the schemas that in the public schema in the tables we don't have any tables. So this is an empty database and as we run the program with DDL auto property create it will create the missing tables. So this is the database that we are going to use and this is a Postgress database. So you can see the URL the username the password and the DDL auto property which is create so that it can create the missing construct. So in this case tables and the dialect that's it. So this is a very simple application file which has the basic details. So if we go back to the diagram we know when the user registers itself it will be intercepted by a controller. So we will start writing a controller to fill the missing pieces. All right. So let's go to the Java folder and here we will create a new file in the controller package. And this is going to be a rest controller. And in this rest controller, we will expose a simple endpoint to register the user with a post mapping because this is going to be a post endpoint. All right. And what we will receive is the user data because user needs to provide the username, email and password. Okay. So whatever user provides in the original request, we are mapping that data to a user DTO and this is something that we will create now. So let me create the user DTO and in this case we will choose a record because we are not going to provide setters and getters record can do that. So let's create a simple record and this record would have three fields email password and username. That's it. Going back to the controller. Now that we have the user DTO, we need to use this information to register the user. And for that we will use another service which is user service. We don't have the user service yet, but we will create this one also. All right, we need to change the return type now and the next step is to create the service. So the user registration controller is complete once it receives the register request which is going to be a post request. It will map the incoming data to a user DTO and that user DTO will be passed to the user service. So let's now create the user service and in this user service we need a method which is the register method. All right. So the first thing this needs to be annotated with service annotation. All right. And in the register method because we need to create a user in the system. So we also need a user entity that is going to be the JPA entity and we will use spring data JPA to store or to perform credit operations on that entity. So let's do that one. We will now add the entity the GPA entity for user and we will store the users in the users table. So the name of the entity is going to be users and then we will use getters and setters from longbox so that we don't have to write them. All right. And then the remaining columns which is username, email and password. And additionally we also need to store the status. So we know that initially when we create the user the user will be created in inactive state. So we also need to store the status and we can use an enum to store the status that is going to be the status enum which can have simple fields like active and inactive. All right. So we will also create this enum and additionally we can also provide the information that from this enum we are going to use the string value not the ordinal so that it can map the actual value in the table active or inactive instead of the ordinal value 0 and one. So the next step is to create that enum. So let's do that. We will keep this in the entity folder. And here we will define the enum to have two values active and inactive. All right. So that's the enum and that there we have the user entity. So the user entity is complete. We will go back to the user service. So once we have the user DTO in the user service, we need to create the user entity. This is the user entity. and then in the end we will set the status as inactive. So as you can see right now we are storing the password in the plain text manner but we know we need to encrypt it and for that we will use brypt password encoder as we did earlier. So let's go back and add the security config at this stage. And in this security config we will define the password encoder. All right, let's go back to the user service. And now we can auto add this password encoder. And now we can use this password encoder to encode the password before saving it in the database. Now the password is hashed. All right. So once we have the user, we know we have to store the user in the database. For that we will need a user repository to perform the cred operations and that user repository will be a JPA repository. This is this is something that we have already done. All right. So this is not a new thing. So let's create a new interface that is going to be the user repository. You need to pass the type parameter of your entity. In this case, that is going to be user. Here it is. And the type of your primary key, which is long in this case. And that's it. We have the user entity. And we need to create the interface not the class. All right. So once we have the user repository we'll go back to the user service and we will also auto add the user repository. No. When we call the save method of the repository, it will save the user entity in the user table and it will return the newly created user. So we will need this newly created user and I will explain in a minute. Now that we have stored the user in the inactive state, the next step is to associate a token. And there are different ways to do this. I will choose the simplest way. So once we have created the user, the next step is to generate the token. So for that check, I'm going to use this created user to check if the user has been created in the database. If yes, then the next step would be to create the token. And that's why we need this created user. So I'm going to put a simple if check here that if the created user's ID is not null that means the user has been created in the database then we will create the token. All right. So for creating the token we will need a token service dot create token and then we will pass the created user. All right. What is this token service? This will be a simple service same as this user service. So let me create a token service now. All right. So the next step is to create the token service. Let's do that in the same way. This is going to be a simple service and we will add the missing method which is create token. All right. So let's implement this method now. So as you know if you remember the diagram here as you know we have another table which is the user token. And in this user token table we store the user mapping that this is the user ID. This is the status of the token which will be active in the beginning and then the token itself. So to store the data in this table, we need another JPA entity and that is going to be user token. All right. And in that entity, we will set the values and the values will be stored in the user token table. So let's go back and here we know we need another JPA entity to store the user token. So we will add a new entity now with the name user token. So let me copy some of the details. So I will put them here and we know the table is going to be user token and I will also copy the primary key part because this is going to be the same and then we need user ID. We also need the status of the token. So we can use the same enum and as before we will say that use the string value and in the end we need the token. All right. So we have the user token entity ready. We will go back to the token service and we will create the user token entity now. user ID. We can get the user ID from the created user that we passed. We can set the status as active because the token has not been consumed yet. And in the end, we need to store the token. So for that we will say set token and we need the token. So how are we going to generate the token? Well, in the simple demo, we can use the UU ID. And when we are productionizing the code, we can also uh append some values to the UU ID. So for example, you can use random UU ID by appending some milliseconds to it to make it more unique or some other metadata. All right. So that is that is simple. So we will create a UU ID a random UU ID and we will convert this value to string and then we will store this token in the token property. All right. So once we have the user token entity we know we need to store this data in the user token table and similarly we will also need a repository a JP repository. So at this stage we will add a new JPA repository for the token and that is going to be token repository and remember this is to be an interface which will extend the JPA repository. The type of the entity is going to be user token in this case and type of the primary key is going to be long. All right, going back to the token service. Now we need to auto add the repository. So this will now store the token in the user token table and we will get the created token and as before we will check if the token has been created. If the ID is not null that means the user token has been created in the table. And if this is done then what we will do at this stage we will send the email to the user because we know the registration part has been completed. So how do we send the email? For that we will add another email service that will send the email. All right. And what we can do we need to pass the token. All right. because that has to be included in the email and the email of or the email address of the user. So we can pass the created user or just to keep things simple we can only pass the email. All right. So now we need to add the email service. So at this stage let me add the email service. like this and this will need a method send email. All right. Now, if you go back to the token service, you can see uh we are not handling any errors as of now. So we are going with the simple flow that if the token is created we are simply checking the ID. If this is not null that means the user has been created and then we are sending the email. And we were doing the same thing in the user flow that if the user is created then call the token service. Now in the real world this can be implemented in different ways like once the user has been created you can trigger a notification for the token service to intercept or in the same way once the token is created we can trigger another notification that can be intercepted by the email service which can trigger the email asynchronously and we can also uh handle the error scenarios. What if the user is not created? If the user is created, what if the token is not created? So we need all these fallback mechanisms, the retries and the error handling scenarios which we are not implementing in this demo. So we are keeping things simple uh assuming everything will go fine and this is basically the happy scenario. But just to point out in the production ready application we need to handle all these things. All right. Right now the flow is synchronous. Once the user is created it synchronously calls the token service and in the same way the token service is synchronously calling the email service. Just to keep things simple because here we are focusing on how to implement this particular scenario. How to create the user in the inactive state. How to trigger the email and once we send the email, how do we verify the user and change the status? So that's the part we are focusing on. All right. So we will go back to the email service now. And here we need to write the code to send an email. And now at this stage I will simply copy and paste the code that we got from the mail trap. So let me do that. So I have copied the text and I will put it here and you can see uh we have the subject the verification this is going to be the URL that we will use in the email. Now if you notice the URL says localhost col80 that means when the user receives the email it will not be able to perform anything because when we click this link the email id will not redirect to localhost because that is local to our system. So what we will do, we will mimic this scenario using Postman. But just for the completeness sake, this is the URL that will go into the email. And here you see the content. You can change the content as you like. That is the usual template that we usually see in the emails that please verify your email by clicking the link below. All right. So uh you can see in the config section we need to provide the token. So if you are registering with Mail Trap, you need to create the API token. I will pass my token here in a second. And once we provide the token you can see we are providing here from to subject text and everything. Now you can see uh the recipient in this case is a single email and this is the email of the user that we created. Okay. So you can see we are simply using that email that we passed from the token service. So if everything goes well this email this email service will trigger an email to the user. The only thing that remains is to pass the token. Now you can again use different ways to pass the token. You can pass it via VM argument. You can keep it in the application.properties file. You can keep the token in a vault. Then you can maybe make an API call to that wall to get the token. So there are different ways. I'm going to hardcode my token in this case. But I will hide it from the uh video. All right. So that completes the user registration phase. The user has been created. The token has been created and both the user and the tokens have been stored in the database. And hopefully if everything goes fine there will be an email to the user. Now we need to implement the second flow. So if you go back to the diagram we need to implement this particular flow to verify the token. So let's do that. For that we will add another controller and we will name that controller token verification controller. All right. And this will have another endpoint to verify the token. So as you know in the email address the token will be appended as a request parameter. So we need to fetch that token. For that we will use request param. This is plain spring boot web. All right. So request param name of the parameter we will keep things simple. All right. So we will store the token to a token variable. Now what we will do once we have the token we will verify the token. So we will say if the token verification service says that this token is valid which means if the token is verified then we will return a response. If not we will return an error response response entity dot we can change the status at this stage. We can say this is bad request. All right. We need to change the type of course. So we have the token verification controller that will start the token verification process. Uh and now we need the token verification service. So let's add that. So let me add the new service in this case. This is going to be another service and we need to add the missing method to verify the token. Now what would happen in the token verification service? If we go back to the diagram, we we know that we need to find the token. We need to find the corresponding user. Then we need to update token and user both. Now all of these steps they require the DB access. So we need to have the repository access for the token and the user. So we need to autowire both the repositories. Now first we will need token repository because we need to read and update the token and similarly we will need user repository. So the first step is to read the token from the user tokens table and we will do that by using token repository token repository dot find by token. Now if you notice why are we calling method find by token. Now if you notice the token repository which is a JPA repository, it provides the read operation read method but that is by ID because that is the primary key. In this case we are not going to read the token by primary key. We don't have the ID of the token. We have the token itself. That's why we need to provide a different method find by token. So how do we write this method? We know this already. We need to simply create the method in the token repository. The implementation of this will be generated by spring data framework at runtime. All right. So it will create a query. It will generate a query on the user token table by token and the value that we passed. Now again there are different ways to do this. Instead of just reading the token, we can add the status check that only find the tokens which are active at this stage. That means that has not been consumed. But to keep things simple again, I'm just going to read the token by the value. All right, you can also do that because we are also storing the token status. Let's go back to the token uh repository I mean the token verification service. So once we have the token from the database, we can apply the check if the user token is not null. That means we found the token in the database a valid token. So the next step is we need to change the status of this token. All right. So earlier when we created the token in the user token table we what the status was that this token is active that token has not been consumed yet but now we know that this is the verification flow the user is verifying the token so we can say that the token has been verified or has been consumed. So at this stage we can say we need to update the status. So we can update the status to inactive now and then we will use token repository to make that update. All right. So the token has been verified. How? Because we actually found the token in the database. So we know the token exists in the database. And once we found the token, we are simply updating the token status that this token has been consumed. So do not reuse this token. The next step is to find the user from the token. And we know that the user token has the user ID. So we will go back to the user repository. And now we will use the method find by ID. And in this case you can see we don't have to write the method because we are querying the user by the primary key. So this is the method that we already get with JP repository. So I'm going to use this method. And what is the ID of the user? Well, that we will get from the user token which is this entity because we know in the user token table we have the user ID. All right. So if the user is present in the user table then what we will do we need to update or we need to activate the user. So we will do the same thing here as well. user dot set status status doactive and then we will update the user. Okay. And once everything is done, if everything goes fine, if the token is not null and the user has been updated, we will return true that the token has been verified. If not, we will return false. So that completes the token verification flow. Now again there are different ways to do this. Here you can see first we are reading the token and uh then we are actually reading the user and updating the user. Now what if the token has been verified but maybe that user does not exist in the database for whatever reason. So you can see we can club the steps maybe in a single transaction that do token and user updates in one go. There are different ways to do this. We are keeping things simple in this demo. So that completes the overall flow of the token verification. Before we run this program, there is one important thing that we have missed and that is the security config because we need to override the security filter chain. All right. So let's do that now and then the program is ready to run. And we know how to do this. We have already covered this in the HTTP basic demo. So here we will say security filter chain because we are going to override the security filter chain. HTTP security. And now we will configure the HTTP security based on this example based on the scenario. So the first thing is we need to disable the CSRF because as we covered this is a purely backend application there is no UI involved. All right. So in this case we can disable the CSRF. All right, once we have disabled the CSRF, we need to also configure HTTP basic, we need to provide the authentication mechanism and we know this is going to be HTTP basic and we will provide HTTP basic with defaults. All right. The second step is to authorize the requests and here we will allow or disallow the request patterns. So in this case because we have only two controllers, we are only implementing the registration part. All right. So the user has not been activated yet. So we need to allow both the endpoints which is the register and the verification. Otherwise the user won't be able to do anything if both the endpoints are secured. The user needs to authenticate. So that's why we need to allow both the parameters I mean both the endpoints. So we will say request matchers API o register and the second one would be / ai/ o and verify. So let me quickly cross check. If you go back to the controller, this is API o verify. Okay. And we are going to permit all and then if there is anything else if there is any other request then that has to be authenticated like this. So what we are saying in the security filter chain that we need to allow register and the verification endpoint but anything else if there is any other endpoint which is accessed uh by this application then that has to be authenticated by spring security. All right. So once we have the application ready let's start the application and then we will check how to register the user and we will also see how to verify the token. So let me do that. At this stage we can run the application now. All right. So the service has been started but there is an error and the error is that it cannot find the password encoder. So the password encoder bean is here but okay we missed the annotation configuration that is why it cannot instantiate the uh beans in this config. So let me do that and retry the application. And this time we can see the service is up. It started successfully. So we have the service up and running. The first step is to register the user. For that I will use Postman. All right. So here we have the endpoint/ API/register and in the body we need to provide the user information username, email and password. So this is going to be the details of that user and this is going to be the post endpoint. So let me hit the send button and this should create the user in the database and we got a 401. So let's try to see what went wrong. So in the logs it says that raw password cannot be null while registering the user. So if we trace the flow to user service here it says the user the raw password cannot be null. Okay. So the problem is if you notice I'm getting the password from the user entity that has not been created yet. So we need to get the password from the user DTO. And same goes with username. All right. And since this is a record, we need to get the password like this and username like this. That should work now. So let me restart the application. All right. So the service is up. Let's retry the request. So this time we can see the user created successfully. Let's go to the database and verify if the data has been inserted. So let me do a refresh. And this time we see the user token and the user token table. So if you go to the user table in the user table we can see the details. The user is inactive at this stage. And we can see the hashed password which is fine. And if we check the user token then we can see the token has also been uh inserted successfully. We see this is the token and the status is active. So from the database perspective everything is working fine. The next step is to verify the token. Now before verification of the token we need to verify if we got the mail if the mail sending part also worked. So for that I will go to my Gmail ID because this is my email address. So that should have sent the email to my email address. So I will go to the Gmail and I can see there was an email just 1 minute ago and this is the text that we uh basically provided in the email body and you can see the uh email link as well the activation link that API overify and this is the token. So what we need to do we need to uh use the verification endpoint from the postman and we need to provide this token. So let's do that. Let me copy the token and we will go back to the postman and then we will use the second endpoint to verify the token. All right. So you can see this is the / ai/verify and the token in the request param. So let me replace my token for this user and this is going to be the post endpoint. So let me hit the send button and you can see we got the successful response token verified. If you go to the database and now if we check the user because the user was inactive earlier but if the verification happened then you can see the status has been changed to active. So the user is activated now and if we check the user token this should be inactive now. As you can see this has been changed to inactive. That means the token has been used. All right. So that's all for this video. That concludes the demo. You can see we learned how do we register the users in the inactive state, how to send an email the activation email to the user using mail trap, how to save the tokens and how to finally verify the token. So we learned how can we change the status of the user depending on the token verification. So that's all for this video. In the next video we will cover another interesting topic on the spring security, another recipe, another uh you can say the use case and uh thanks for watching this video. That's all for now.