Serverless Architecture: Pain 1 - OAuth Client Credintials, Auth0, Vercel and Serverless

Building applications with Vercel, Auth0 and NextJs is a breeze. You can simply just fork a template from Vercel. Connect your GitGub account, assign some domains via DNS and get going in a very short time. The ease of use and developer experience is what makes Vercel a very good fit for very many uses case creating webpages or small web applications. This post is about the snarky details when stuff get more tricky to implement, and it involves Auth0.

One of the most common use cases you can have when creating a web application using NextJs and Vercel is where you have a user visiting a page -> which then calls some protected /api route for fetching some data to display.

In this scenario you usually deal with authorization code flow for getting new access tokens to call the protected routes. This is always fine because you usually will never hit any limits in Auth0 on the number of users (or MAU) you can have, and it is basically free to create as many access tokens for each of the user you can.

The above scenario is fine and easy to implement, the problem arises when you are trying to do where you need to call any other downstream servers or any third party services which is not implemented by a static environment variable or API-key. The few options you have to solve it are a following:

You simply pass through your token to the downstream service. This requires you to own the down stream service and have it protected with the same issuers as you use.
Or you choose to do a server-to-server integration using client credentials. (In Auth0 terms Machine-2-Machine integration). This is also applicable when integrating with third parties using client credentials and not using API-keys.

The pain is related to the longevity and how many times you need to issue the access tokens

So why may it become a pain for you?

Access token can be valid for 1 day (default in Auth0)
Cold starting of serverless functions. e.g. very sparse traffic on your application but enough to hit limits
Serverless function with 30-60 sec timeout
Caching and reuse of the same issued access token

First and foremost the free tier of Auth0 only allows you to issue 1 000 Machine-2-Machine token each month. Mark mye word, it is not 1 000 active/valid access tokens, it is 1 000 issued tokens.

So to break it down in numbers with 1 000 issued tokens you can do the following

1000 tokens / 30 days ≈ 33.33 tokens/each day

With a longevity of one day you can issue 33 tokens for 33 different applications/serverless function you have each day. (Requires that the access token can be cached for each function)
You can call the serverless function only 33 times each day if the access token cannot be reused (Cold starts and not cached)

So what does this mean? You cannot lower the expiration time of the access token because you will still only be able to issue 33 token each day or call the functions 33 times per day.

So the only solution to this problem is to be able to either cache and reuse the access token or rotate via automated secret managers like Doppler, GSM or AWS secrets manager. Hey, you only have to add one more integration and tech to your stack?

If you are able to reuse the token and don't have any cold starts e.g. heavy traffic, then it might not be a problem for you. For workloads that requires a few calls here and there and you don't want to issue tokens only for a short period of time, that will only end in increased cost.

On other matters. I really love Vercel, GitHub and the ease of use just to get going creating stuff. FYI: This blog is even hosted on Vercel!