Skip to content

OAUTH2 Resource Server Token Validation#

How Does Resource Server Validate Token?#

  • In the OAUTH2 Flow, we have discussed about main flows for applying OAUTH2 and we can know that everytime the Client want to access the Resource Server, it must provide the token which is received from the Auth Server to the Resource Server. So then the Resource Server can validate and response data to the Client.
  • Usually, we will have three main ways to apply for Resource Server to validate access token.

Direct Api Call#

 #zoom

  • As you can see in the image above, every time the Resource Server receives the access token from the Client, It has to validate that token with the Auth Server by calling the Auth Server api for token validation. Because these are two different servers or two different applications handling different responsibilities. Thus, the Resource Server is not aware of the access tokens issued by the Auth Server to all the clients. So the Resource Server have to send the access token to Auth Server for validation.

Common Database#

 #zoom

  • From the image above, we can see the Auth Server and the Resource Server is connecting to the same database. So whenever the Auth Server issues an access token, it can write into the database and the Resource Server can connect to this database to get the access token and validate it with the one received from the Client.
  • In this scenarios, the Resource Server doesn't have to rely on the network interact with the Auth Server.

Token Signature#

 #zoom

  • In the Token Authentication With JWT, we know that 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.
  • Following the same approach, the Auth Server can generate an access token by using some encryption algorithm with the secret. Then, whenever the Client sends the same access token to the Resource Server, so the Resource Server doesn't have to make a call to Auth Server or doesn't have to look into the database. It can simply check the signature or hash value of the token generated with the encryption algorithm that it maintains to understand the token is valid or not.

Summary#

  • Every approach has it's own pros and cons. In the Token Signature approach which is used for validating the token signature, so you will never depend on the network to call Auth Server or database. But if we have a clear and real time checking with Auth Server, you can always rely on the Direct Api Call approach. But if you don't want to overburden the Auth Server network so you can maintain a Common Database which can be leveraged by both Auth Server and Resource Server.

See Also#

References#