Custom claims: How to add the user app (DB) id to the session cookie? #936
Replies: 1 comment
-
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
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
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).dbId
).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)".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
dbId
is returned to the frontend;dbId
is given tosignUp.create({ emailAddress, unsafeMetadata : { dbId }})
{{user.unsafe_metadata}}
)In theory, at this point we have all that is needed in place:
dbId
in the db.dbId
in the session cookies (forever, as it is part ofunsafe_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
dbId
asunsafe_metadata
tosignUp.create
.middleware.ts
level, check if session cookie hasdbId
unsafe_metadata
(orpublic_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:
Beta Was this translation helpful? Give feedback.
All reactions