Custom claims: How to add the user app (DB) id to the session cookie?

[Izhaki]

Came across Clerk yesterday, and hugely impressed. We are doing a POC to asses it as a possible Auth0 replacement.

However, it is hard to get your head around this backendless flow, specifically once one is accustomed to Auth0 universal login flow (which is backend centred).

I keep on wishing there was an edge-runtime API to make all the calls to Clerk, instead of doing all from the frontend (and I have read the rationale behind the current design in this answer by @SokratisVidros). A quick look at core/resources suggests most of the code is backend compatible.

The frontend nature of Clerk is relevant to the case below.

I'm trying to figure out how to do what I believe is the (rather common) use case below.

Context

• NextJS
• Vercel Deployment
• Ideally all that can should live on the edge
• Passwordless Email OTP only
• Using custom flow: useSignUp & useSignIn

Use case

Our database is designed so each new user gets an auto-increment id, which is then used as a key in various relationships; (had we used the sub auth-provider user id for relationships, this problem would not have existed).

• User signs up.
• Once successful, the user is added to the app DB, with its email saved and an allocated auto-increment id (integer - dbId).
• We want that dbId in the session cookie, so with every API request we know it, rather than having to ask the DB - "What is the user id for this user email (or auth provider user id)".
• Same for sign ins - we want the session cookie to include dbId.

The solutions described in Sync data to your backend are not exactly what's needed here.

Also, it is worth mentioning that the possibility to log in users without them navigating away from the page is hugely attractive to us - a flow involving redirects (like Auth0 universal login) does not allow this.

Possible Solution 01

• The user clicks Submit Email;
• The front end sends a request to the backend with the user email;
  • concern: This is a public non-authenticated API which create users.
• A new record created on the app DB;
• The dbId is returned to the frontend;
• The dbId is given to signUp.create({ emailAddress, unsafeMetadata : { dbId }})
• (The session token is customised to include {{user.unsafe_metadata}})

In theory, at this point we have all that is needed in place:

• The user email and dbId in the db.
• That dbId in the session cookies (forever, as it is part of unsafe_metadata)

A further improvement would be to create a webhook back to the app that notifies it a user has been created - this way the app can tell that user has completed signup (so it can purge incomplete sign-ups, and not send the user any communications via email).

Am I missing anything? Are there any other options?

Possible Solution 02

• Not create a db user before signup is done.
• Not pass the dbId as unsafe_metadata to signUp.create.
• Rather, at middleware.ts level, check if session cookie has dbId
• If not, create the user on the DB, and use the Clerk Backend API to add unsafe_metadata (or public_metadata)

Not sure how with this solution you can ask to "refresh" the session cookie (so it includes the metadata and hence the dbId) - this is to prevent that user initiating the "if not" case above until they login again.

How does it work with Auth0 universal login?

You do not to store these as custom claims.

Rather, one can hook on the callback and modify the session there:

async function afterCallback(
  req: NextApiRequest,
  res: NextApiResponse,
  session: Session
) {
  session.user.dbId = await db.getUserIdByEmail(session.user.email);
  return session;
}

export default handleAuth({
  async callback(req, res) {
    try {
      await handleCallback(req, res, { afterCallback });
    } catch (error: any) {
      res.status(error.status || 500).end(error.message);
    }
  },
});