Page Comparison

...

1. Refreshing the client token by backend modules making the request

   • Set “Refresh Token Max Reuse” to N > 0
     Right after the start of the import, a new AT+RT pair needs to be obtained to avoid situations where the RT is invalidated due to the user logging out or obtaining a new token. Additionally, if the value of this Refresh Token Max Reuse is strictly monitored to match the number of modules, it might work. However, if an unauthorized party accesses the key and requests a new pair of tokens, one of the modules could fail with an exception.

   • Drawbacks: A module must store a token pair for a specific jobExecutionId during operation. After a reboot, the module receives the token pair from a Kafka message. However, if that token pair has already been used to request new tokens, and the Refresh Token Max Reuse limit is reached, the module cannot obtain a new token pair. This creates a potential failure point, as the module won't be able to refresh tokens after a reboot, impacting its ability to continue the job.

2. Obtaining a #SYS Token that does not expire: (Refer to comment).

   • The ticket linked to this comment is currently in the OPEN state, so it's uncertain how well this approach works.

   • Drawbacks: The data import process relies on user permissions, which is why a client token is required.

3. Separate token storage (Redis or a database schema):

   • This solution allows tokens to be stored by userId and retrieved as needed.

   • Drawbacks: Security issues (Restricting access to storage). There's a risk of desynchronization between the storage and Keycloak. Additionally, maintaining the storage introduces extra overhead, and performance issues may arise.

4. Broadcast token distribution (Kafka, RabbitMQ or , ActiveMQ):

   • Tokens are sent through messages, allowing synchronization across componentsmodules.

   • Drawbacks: It requires complex configuration and maintenance. Message delays or losses are also risky, leading to authorization issues.