Hello everyone!
I’m working on a project using Strapi and I’m trying to integrate an external authentication provider, Clerk, to handle user authentication. My goal is to:
Override the users-permissions strategy and the authenticate method (in plugin-users-permissions/server/strategies) so that it validates an external JWT issued by Clerk and uses Clerk’s authentication and user management system instead of Strapi’s default JWT.
I’ve been looking through the documentation and plugin code, but I’m unsure about the best way to override the existing strategy and hook into the auth process.
My Questions:
Is there a clean way to override the users-permissions auth strategy to validate external JWT tokens from Clerk? How can I bypass Strapi’s built-in JWT validation and rely on Clerk’s JWT? Has anyone integrated external JWT authentication and can offer guidance?
Thanks in advance!
This topic has been created from a Discord post (1287784008867909778) to give it more visibility.
It will be on Read-Only mode here.
Join the conversation on Discord
Apart from forking the code and modifying it yourself, there is no build in solution for this. I have done it with firebase auth but ended up just removing firebase auth and sticking to strapi. Managing users in 2 places is a pain.
I’ve never seen a clean easy implementation since I’ve been around Strapi (roughly 2017) for validating external tokens.
The problem usually lies in the fact of matching a token to a user since ours just use the user ID
And you also need to be able to convert valid tokens into our internal (and undocumented) auth scopes
Hi<@211722558385553408>, for testing purposes, I overrode the JWT service and applied a patch to the users-permissions strategy to authenticate via email. It’s not the cleanest solution, but it seems to work for now.
That said, I’m not sure I fully understand your point about the authentication scopes. Could you clarify what you mean by that? I’d appreciate it if you could elaborate. Thanks a lot!
It depends on what your intention is, in our case we match the authentication and authorization within users-permisons so specific users are attached to specific roles with specific permissions. If you override the user authentication without having some kind of mirrored user/role within Strapi itself Strapi can’t generate the auth scopes based on the permissions because such a user doesn’t exist
This is typically why you don’t see very many examples of this usually because when people do this they want to “outsource” both authorization and authentication to a 3rd party
Most of the time we see this (some of our EE customers do it) they generally end up disabling user authentication within Strapi entirely, use something like an API gateway and have that gateway handle all authentication and simply forward the requests to Strapi using server to server API tokens
Or the alternative if they want to use 3rd party authentication only they just end up using our built in 3rd party auth providers which still uses the built in Strapi users/roles/permissions and issues Strapi JWTs but mixing and having Strapi authenticate using a 3rd party JWT is almost never done because of how complex it is