Concept clarification: where/how to persist bearer token?
Unanswered
Gulf menhaden posted this in #help-forum
Gulf menhadenOP
A broad question in the context of learning and experimenting with nextjs on a hobby app (using the old folder layout):
I have a single /API route that simply fetches another external api for content. This other external api requires a bearer token, and in my naive implementation I just got the token the via a manual POST and saved the string token as env variable, which is clearly not the solution since it expires every month and I need a way to automate this.
My first thought is to somehow create a middleware (overshoot for a single handler but I'm trying to exercise), that checks if the auth token is available / not expired and if not to refetches it and pass it to the next function which will effectively fetch for data. Here is where I'm missing it, where should such token be stored (because I guess requesting another auth for each page visit is not correct) ? Necessarily on an external service, like a db that needs to be queried? Because my uneducated guess is cookies are on the browser side, and the API that is run on the server does not have access to that? Wrong? And if so, is it safe to store such a token in the browser as a cookie?
I have a single /API route that simply fetches another external api for content. This other external api requires a bearer token, and in my naive implementation I just got the token the via a manual POST and saved the string token as env variable, which is clearly not the solution since it expires every month and I need a way to automate this.
My first thought is to somehow create a middleware (overshoot for a single handler but I'm trying to exercise), that checks if the auth token is available / not expired and if not to refetches it and pass it to the next function which will effectively fetch for data. Here is where I'm missing it, where should such token be stored (because I guess requesting another auth for each page visit is not correct) ? Necessarily on an external service, like a db that needs to be queried? Because my uneducated guess is cookies are on the browser side, and the API that is run on the server does not have access to that? Wrong? And if so, is it safe to store such a token in the browser as a cookie?
4 Replies
in general, you can have a token stored in a cookie, which can be retrieved from server side code as cookie is just a part of HTTP request headers.
Indeed Auth.js has a mechanism to store tokens safely in a cookie(JWT encrypted)
Usually OAuth providers such as Google returns an access token so you can bake it inside JWT, then retrive it from server side then invoke Google API along with the token.
Indeed Auth.js has a mechanism to store tokens safely in a cookie(JWT encrypted)
Usually OAuth providers such as Google returns an access token so you can bake it inside JWT, then retrive it from server side then invoke Google API along with the token.
oh. bear toke, api key or something should not be exposed to client sides such as cookie. keep it in server side like ENV or secret key services AWS/Google/Azure provide.
Gulf menhadenOP
hmm, I was wondering, since the bearer authorizes my server to ask for data, passing that to the client would be also conceptually wrong. Maybe the fastest solution is Vercel KV, so storing that auth token to a database known only to the server? I never used that though
actually the API key to access Vercel KV is managed as env variables in Vercel build server. so u do not need to store keys to DB. your coworkers could steal the keys stored in DB. It is not secure. at big companies, keys are stored in secret key managed services of cloud venders, where only limited developers who have admin privilege, can access keys.