hardik.handa
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:
- 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.
- 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.
Thanks
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #elixirconf-us
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
tangui
Calling the authorization server (AS) every time is indeed not performant, and it might even lead to some problems:
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_tokenerror 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
TeslaOAuth2ClientAuththat implement some.hardik.handa
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.