Next.js Discord

Discord Forum

IGDB Bearer Token Refresh Approach?

Answered
Transvaal lion posted this in #help-forum
Open in Discord
Transvaal lionOP
Hi All,

Fairly new to React + NextJS and Typescript, so apologies if this is a fairly simple question that's escaping me.

I'm using the https://api-docs.igdb.com/#getting-started API to do a fetch call to get a list of games.

This fetch call is authorized via a bearer token. This token has a life expectancy of ~60 days.

What is the common approach, or how should I handle refreshing that bearer token when it expires, and where should I store the current token. (I do not have a database currently, and would prefer to not set one up for a single value).

(Not expecting fully detailed anwers, but guidelines here)

Thank in advance
Answered by Exzotic
If your on vercel, you could use [edge config](https://vercel.com/docs/storage/edge-config) or [KV](https://vercel.com/docs/storage/vercel-kv)
View full answer

33 Replies

Transvaal lionOP
After some hours of googling and typing out this question, I've opted to use https://github.com/typicode/lowdb, though I am curious to see other approaches, or is using a DB really the best method
American Chinchilla
Hmm i havent used oauth2 yet
But i dont think there is any need to have the tokens stored
By default when you sign in, that token is stored via http cookies etc
After it expires you just need reauthenticate, there may be more info in the doc about this
Transvaal lionOP
This isn't via oAuth though, this is all server side via this https://api-docs.igdb.com/#authentication
Transvaal lionOP
self update: while lowdb works great locally, doesn't work so well on vercel serverless. Looks like EdgeDB is a OK candidate for this https://www.edgedb.com/
Schneider’s Smooth-fronted Caiman
Does the endpoint provide a refresh token?
Transvaal lionOP
There is no refresh token
{
  "access_token": "access12345token",
  "expires_in": 5587808,
  "token_type": "bearer"
}
is all it proivdes, the twitch docs recommends not trusting the expires_in, but instead, refreshing when you get a 401
Schneider’s Smooth-fronted Caiman
Okay if so I think the best you can do is authenticate again when it expires. You can securely store the token in cookies and if you are doing a server side call to the api you can use {cookies} from next/headers and use the cookies.set method
Transvaal lionOP
Is taht stored on the server? or the client side? This key is not per user/client, but is used on the server only
Schneider’s Smooth-fronted Caiman
the cookies.set("key": "value/token") stores the token in the users browser. note that you have to use the "use server" at the top.
Transvaal lionOP
hmm, kk, Let me write some quick demo code here to make sure I understand correctly, since I'm worried I'm phorasing stuff wrong
Schneider’s Smooth-fronted Caiman
Refer to this short documentation
https://nextjs.org/docs/app/api-reference/functions/cookies
Transvaal lionOP
/lib/igdb.tsx
function getGames() {
  response = fetch('externalAPI.com',
    headers: {
      'client-id':  process.env.TWITCH_CLIENT_ID
      'Authorization': `Bearer ${LONG_LASTING_AUTH_TOKEN}`,
    }
  }

  if (response.status === 401) {
    refreshAuthentication();
  }
  return ...;
}

refreshAuthentication() {

       const response = await fetch(
            "https://id.twitch.tv/oauth2/token?" + new       URLSearchParams({
                    client_id:      process.env.TWITCH_CLIENT_ID,
                    client_secret:  process.env.TWITCH_CLIENT_SECRET,
                    grant_type:     'client_credentials',
                }).toString(),{ 
                method: 'POST',
            }
        );

....

LONG_LASTING_AUTH_TOKEN = response.data.access_token;

}



app/games/page.tsx 
export default async function Page() {

  const games = await getGames();
.....
In the above example, it's reasonable to use the clientside cookie for the LONG_LASTING_AUTH_TOKEN ? which is not unique per user?

Or am i thinking about this wrong, and it should be treated as unique per client , and stored in the client cookies?
Exzotic
Are you wanting to use your access & refresh token for all requests or oauth tokens from the current user / session?
Transvaal lionOP
there is no oauth token if im understanding this all correctly
the users have no login information what so ever, so the data im grabbing is not unique to that user at all... but I need to be authenticated to use the data (https://api-docs.igdb.com/#account-creation)
so like... technically every user uses the exact same tokens?
apologies, idk if I'm explaining this well
Exzotic
Right I see
Transvaal lionOP
Twitch referes to this as an "App access token" https://dev.twitch.tv/docs/authentication/#app-access-tokens
So I suppose the cookie approach works... but then I'm handing out unique access tokens to every new visitor for 60 days... which is fine, I'm just not sure if thats the correct approach
Exzotic
You probably don't want those tokens to be public / accessible by the user
As I assume they are from your account / app
Transvaal lionOP
Also increases total API keys I imagine, since 10 users with unique access tokens = 10 api calls... VS 10 users with the same access token can be cached at 1 API call... (and IGDB heavily limits calls)
@Exzotic As I assume they are from your account / app
Transvaal lionOP
the app yes, they are generated via client id/secret id of the twitch app... so yea.. it does open up whatever access that has
writing to a json file worked perfectly on the server side... tucks it away in long term storage, if I need to update it... juust update the file and carry on. Just that doesn't work well on serverless
Exzotic
If your on vercel, you could use [edge config](https://vercel.com/docs/storage/edge-config) or [KV](https://vercel.com/docs/storage/vercel-kv)
Answer
Transvaal lionOP
Thank you, I'll dig into edge confg