Nextjs-auth0: Be able to connect to multiple APIs

[jvorcak]

Hi, thanks a lot for this library, I like Auth0 as well as Next so I appreciate that something like this is here :)

Describe the problem you'd like to have solved

I'm having a Next.js app that connects to my Django API. I've listed my Django API in my Auth0 console and I'm able to authenticate and do requests to it. However, my users authenticate using Github and I need to get IDP access_token in order to do queries to Github API from my Next.js API routes. When you have a look here you realise I need to call Auth0 Management API to get that token.

With this architecture, I'm not really sure how can I call multiple APIs registered in my Auth0 console. Is that even possible?

Describe the ideal solution

In case this is possible today, it should be listed in README, probably here

[adamjmcgrath]

Hi @jvorcak - thanks for raising this

When you have a look here you realise I need to call Auth0 Management API to get that token.

The documentation you've shared recommends the client credentials flow - so getting the IDP access_token will be machine-to-machine. So you don't need to log the user in with the Auth0 Management API audience to get a token for it.

[jvorcak]

@adamjmcgrath ah thanks, I think now I understand, they want me to use my backend to get a token using my secret + id, so technically I don't need this in my use case. However, it would still be a case if I have multiple backend APIs right?

---

Can I ask what is the best practice here? I need to get Github API access_token, so that my backend (Django API & frontend can use it. Is it OK to store them in some SQL table / cache for my server/client? If I need it, I'd look it up in that table/cache or request it using the flow above. Access tokens could be passed to a backend or frontend via REST API.

Or what is the best practice there? I've read all docs I could find, but I can't find anything that recomments/forbids storing access_tokens in some SQL table and regenerate them after they expire.

Thanks a lot!

[adamjmcgrath]

Hey @jvorcak

technically I don't need this in my use case. However, it would still be a case if I have multiple backend APIs right?

We tend to recommend representing multiple APIs using a single logical API for this use case.

Alternatively, for each new audience, you'd need a new login. You could of course do the second login for the second audience using silent auth and prompt=none to avoid the user being prompted again.

The getAccessToken helpers of this SDK will only give you the last AT, so you couldn't use that, you'd need to store these on the session separately. Something like this would work:

// /api/auth/login-a.js
import { handleLogin } from '@auth0/nextjs-auth0';

export default async function login(req, res) {
  await handleLogin(req, res, {
    authorizationParams: { audience: 'audienceA' },
    afterCallback(req, res, session) {
      session.accessTokens = {
        audienceA: {
          accessTokenExpiresAt: session.accessTokenExpiresAt,
          accessToken: session.accessToken
        }
      }
      delete session.accessToken;
      delete session.accessTokenExpiresAt;
    }
  });
}

// /api/auth/login-b.js
import { handleLogin } from '@auth0/nextjs-auth0';

export default async function login(req, res) {
  await handleLogin(req, res, {
    authorizationParams: { audience: 'audienceB', prompt: 'none' },
    afterCallback(req, res, session) {
      session.accessTokens = {
        audienceB: {
          accessTokenExpiresAt: session.accessTokenExpiresAt,
          accessToken: session.accessToken
        }
      }
      delete session.accessToken;
      delete session.accessTokenExpiresAt;
    }
  });
}

// /api/my-route.js

export default async function(req, res) {
  const { accessTokens } = await getSession(req, res);
  // accessTokens.audienceA.accessToken and accessTokens.audienceB.accessToken
}

Also, you'd need to be aware that storing many tokens in the session cookie will start hitting header size limits, but you should be alright with 2 ATs.

Or what is the best practice there? I've read all docs I could find, but I can't find anything that recomments/forbids storing access_tokens in some SQL table and regenerate them after they expire.

You could store them in the encrypted session cookie (see above). Or, our express-sdk supports custom session stores (which we plan to do too), which lets you store access tokens in any compatible session store, so I don't see an issue with that either.

[jvorcak]

Thanks a lot! I guess we can close this now, thanks for all your answers.