teddiebui / AromatherapyWebApp

0 stars 0 forks source link

Develop KeyVault #7

Closed teddiebui closed 2 months ago

teddiebui commented 2 months ago

KeyVault is a feature that enable Application that implementing cryptographic keys to be changed for every interval time, which extensively enhance the security aspect of an Application.

KeyVault in the scope of this Project

Implementation Strategy

teddiebui commented 2 months ago

Developed a little bit which was integrated inside AuthenticationService..

Will develope it full scale later on..

teddiebui commented 2 months ago

After discussion, we found some issue

  1. Key Error decryption exception when key are changed. Let's look at a typical study case:

    • We have microservices using JWT for communications, thus they will need to get keys: private key for encryption, and corresponding public key for decryption and furthur validating the token.
    • We will look at the time windows where Users is having there session active, means their refresh key (probably, also for access key) is active, thus if the rotation never happens, their usability wont be affected.
    • But what if rotation happens while their session is active? problem arises from here. When they are using the web normally, and the rotation happens, their next request to the server, will have their Token decrypted with new public key, thus leads to Key Error exception. In order to by pass this error, they must use the previous public key for the decryption for this token. Yes, and the straight forward solution is to somehow cache the previous key. By caching the keys, the microservie whenever facing the Key Error exception, they can use the cached key to decrypt tokens.
    • But what if cached key also cause Key Error exception. In order to understand the cause of that scenarior, we must have to look back at the flow. When you do so, you will conclude the problem with one question: "Under what scenarior, both keys wont decrypt the token?". Yes, and the answer is: those token encrypted with keys that no more being "current key" and "cached key", means their session has been expired throughout 2 rotations. Or simpler, their session is over 12 hours and expired. In that case, their token's corresponding public key wont be cached anymore, thus microservices now can't have any ways to validate the tokens. That would be very a suitable thing for those expired session: they need to login again!! and they will be! So the final solution for this scenarior is that, clients with expired token OR failed decryption with both "current key" and "cached key" will be identified as expired session, thus need to login again, so in your case you should return 400 code.
  2. Because the private key needs to be confidentials, then which service will hold this keys? Answer: the one who issue the TOken will hold the private key.

    • the issuer will subscibe to KeyVault to be receiving both private and public key for refresh token
    • the issuer will also subscribe to KeyVault to receive both private and public key for access token.
    • If for some reason, KeyVault got some error and stopped working, the issuer can use their current key as long as they need.
    • other microservice can only hold public key, and will also subscribe to KeyVault to receive this key, so synchronization will happen to make sure issuer and consumer of token will have both corresponding key.
teddiebui commented 2 months ago

While in the development process, we found that AuthenticationService is hardly coupled with KeyVault, what is it cannot works without KeyVault and if this service is down, so as the AuthenticationService, so we will integrate the KeyVault inside AuthenticationService, make it a whole complete service

teddiebui commented 2 months ago

close first