We have been discussing a lot about operations over and over, saying that operation several issues,
the access to guns and refresh tokens to the client and client.
Every time they want to access a particular resource, they will share the access token issued by the
operations over to the resource.
So what level?
We also understand, like every time resource server receives access token from the client, it has
to validate that with the operations of because these are two different servers are two different applications
handling different responsibilities?
Definitely.
Resource Server is not aware of the access tokens issued by the operations that were to all the clients.
So there should be this for the resource server to validate that access token with the operation.
So for the same, we have three different ways that most of the other nations follow, and you can also
follow any one of them based upon your requirements.
The very first and basic way of violating the access token by a resource server with the authentication
services by making a yapper call in the backend, like whenever a resource over this is the access token
from the client, it can simply call and rest up a call to the Australian.
So by sending a resume, this access token from this client daily, do you approve it or not?
When Ottawa says, OK, this is the correct access problem which is issued by me only and exploration
time also is not met, then in such scenarios it is so server will go ahead and issues the protected
resources that client is requesting.
So this is the basic first of it.
And the second way is by having a common database, like whenever an Australian server issuing an access
token, it can write into a database and the same database can be pointed by the resource server also.
So in such scenarios, we saw server don't have to rely on the network to interact with the observer.
It can directly check in the database whether the access can result from the client is really issued
by the observer or not and what time it is sure whether it is expired or not.
All sorts of details can be validated by using a common database between observer and resource server
as shown in this figure.
Finally, the last approach is that this also can validate the signature of the token.
If we can recall from our JWT tokens, the signature of the tokens can be validated by having some secret
keys maintained by the both parties to make sure that no one is tampered.
So following the same approach outside of work can generate a token access token by using some encryption
algorithm with the secret.
So whenever someone sends the same access token to the resource server in this scenario is also what
don't have to make a call to.
The alterations are it doesn't have to look into the database or it can simply check the signature or
hash value of the token generated with the security that it maintains to understand if the token is
valid or not.
As you can see, every approach has its own pros and cons.
If you see the last approach, which is violating the token signature in this scenario, you will never
depend on the network to Calderazzo our database.
But if we have a clear and real time checking with the observer, you can always rely on the first approach,
which is through that recipe calls.
But if you don't want to overburden your observer network in such scenarios, you can maintain a common
database which can be leveraged by both observer.
And it's.
So with this now, we also have a clear understanding what are different ways that Isaza was valid access
token with the alteration.
So now we have a clear understanding on all the parameters that we have inside.
What framework?
Let's try to wrap up this section by discussing the summary of it in the next video.
Thank you.
And see you in the next lecture by.