In this video, let's try to enhance our application to use the JWT tokens instead of default generator
ones for the same.
Firstly, we have to add these three dependencies related to Jason Webb tokens inside our Pontotoc symbol
post that go to the project security config here we can disable the CSR of.
The reason is JWT itself is a token that we can make sure that you're calling my back and is a valid
person because for every request I'm going to violate the token that they are going to provide to me.
So if you again enable CSR on top of it, it will be a redundant pass to your server.
That's why I'm going to disable it and we are going to make sure that you're calling to my back.
An application is the same one who initially made a request with that login operation that we can achieve
using the JWT token that way and going to disable the SRF by calling disable.
Now I have disable the CSR next.
If we can recall, by default, additionality is getting created by the spring security framework and
it is getting stored inside the EU position of myself.
So first I have to disable the default behavior for the same.
I'm going to write a simple configuration just before my car's configuration.
And you can see this is the configuration that I have written where I'm trying to say to my spring security
framework, don't create any history type situation and tokens.
I will take care by myself.
And for that reason, I'm just saying to the framework that I'm going to use the statelets, security
sition, creation policy, which indicates security framework not to generate any tokens.
And there are other values also inside this session.
Creation policy always is the one which I always try to create a history to be sition token and never
means it will never generate, if required, means only in the scenarios where, if required, it will
generate and statelets means it will never generate.
The difference between the never and statelets is never will never create a token, but it will leverages
if it is already present inside the history.
So that's for valid values on the side note.
But here we are using statelets to indicate never, ever create the tokens for our application and will
take care of it.
By now, when we generate a JWT token, we are going to send inside the header with the authorization
had their name and it's a value for the same inside our cards configuration.
I have to allow that had to go to my applications, whatever is consuming my backend application services
for the same.
I just have to add a new line inside my card configuration, which indicates that I want to expose the
headers from my back and to outside for internal applications or any other applications, which is consuming
my services with the name authorization inside it.
So this will expose our head to to the other applications that are consuming our backend application.
So to revise, we have made total three changes here.
One is firstly we disable the CSF since we are going to level the JWT tokens.
And the other one is we indicated spring security framework to not generate any tokens by following
the policy of stateless.
And the last one, we made configurations inside our cars to make sure whatever authorization header
that we are going to generate to get exposed to the UI application.
Now I will write a filter so that I can configure and fit in to my spring security framework.
So my requirement is during the initial login into my application, I have to generate a token and for
any other scenarios where the user want to access a protected resource.
I want to validate whether the token that got generated by my server initially is really a valid one.
Are it got tampered or not for the same in the next video, let's try to create the filters to generate
the JWT tokens and validate the same and eventually configuring them inside our spring security flow
by using the methods add filter before and after that after.
Thank you and see you.
And then.
By.