Maintaining Client Credential State

Planning on integrating with a client which accepts Oauth2 client credential based Token. The token validity is 1 day for now ( must mention that the client is completely internal and has no access to internet ).
Now there are two approaches that I am seeing fit:

  1. Either call for oauth token as a plug before every call to that client, fetch the token ( Seems like an overkill to be doing before every call to that client.
  2. Fetch the client token once everyday or whenever a new node is getting spun up, and then store it somehow as a state and then fetch the token just internally from that state everytime we have to call that client, if we get 401 on any call from the client, we reset the state, so that it leads to fetching of the token again.

Now I am not sure, should we be using GenServer for this or should we use Memoize for this. Any help or suggestion is more than welcome.


1 Like

Calling the authorization server (AS) every time is indeed not performant, and it might even lead to some problems:

  • if the AS discards the former access tokens (ATs), you might have an in-flight request hitting the target API with an already invalidated AT
  • otherwise you’ll flood the AS with new ATs to store, and you might hit some limits

GenServer is a good fit for this problem (compared with ETS) because, even though request go through GenServer sequentially, you’re assured that in case the AT is expired, the first request hitting the GenServer will trigger token renewal and the others will just wait without requesting new ATs as well. Although if you have a very high number of processes making API requests, you might hit a bottleneck compared with ETS.

Note that some ASes only support 1 AT per client. If you’ve a multinode deployment, that might be a problem.

If you’re using Tesla, you could even write a middleware dealing with detecting expired tokens, requesting a new one when receiving an invalid_token error code (from RFC6750 - 3.1. Error Codes) and replaying the unauthorized request.

If the AS you’re using requires a complex client authentication scheme, you can take a look at TeslaOAuth2ClientAuth that implement some.


Thanks that really helps to bring perspective.
As I am new to elixir, so i will give GenServer a try, all of my thoughts in the question was from detailed look at the documentations for that, so now that I have sort of an idea that I could be on the right path, i will go ahead and take a pass on that through a POC.

Also the AS does support 1 AT per client, but that AT has longer validity of around a day or something, to relieve / reduce chances of any dead lock situation, but having said that TeslaOAuth2ClientAuth looks great as well, will take a pass at it later.

Thanks again for helping out.