Feature Request: additional third party authentication provider support

[ctrlemo]

Hi Nhost team.

I noticed a new support for integration third party Authentication service.🎉

https://docs.nhost.io/guides/auth/jwt#external-signing

https://docs.nhost.io/guides/auth/sign-in-idtokens

But I am a bit confused now as to what route to take in order for me to simplify my current implementation.

For a couple of years now I have been using Auth0 for authentication. My Nhost project has a custom function that excepts a Auth0 JWT and returns an Nhost compatible JWT. The function validates, decodes the Auth0 JWT using my Auth0 tenant JWKS endpoint public key. And then I pass over the custom claims, roles etc over into Nhost JWT. Between Nhost Hasura and Auth0 I also sync some user data to a custom postgres table when the user is created in Auth0 and when a user logs in through Auth0.

My current implementation is working fine.
But after seeing the new Nhost features for JWT, I was thinking if I might be able to get rid of some custom solution, and instead switch to using your solutions.

Sign In with ID tokens
https://docs.nhost.io/guides/auth/sign-in-idtokens
Right now I see, google and apple are supported. Auth0 has support for id token as well. Which makes me wonder if this would work for Auth0 too.

• Is it the goal to eventually add support for more providers like Auth0, Clerk, etc using this approach?
• Are you looking for contributors for the project to add support for Auth0 and others?
• Using this approach, does the Auth service actually also create an entry in the auth.users table based on the idtoken that was passed to it?

External Signing
https://docs.nhost.io/guides/auth/jwt#external-signing
This seems simplest approach, because you can just pass the JWT from the 3d party right away in your graphql calls without an additional exchange for Nhost JWT.
But using this means that Auth service will be disabled, which is not what I would like.

In the near future I want the best of both worlds:

• One group/type of users on Nhost Auth service (email/password,SMS OTP, social Sign in,etc)
• Second group/type of users on Auth0 (I rely on Auth0 Actions, like checking country of request, current time and some other stuff before allowing a user to sign in)

But at the same time not having to maintain to much custom code going forward.
So wondering if you can shed some light on what approach I should consider to build upon going forward.

[dbarrosop]

Re idtokens, yes, we want to support this for any OIDC provider, we just took a bit of a shortcut to support native authentication on macos/ios/android. I don't have a timeline for this though, I'd love to have this ready during 2025Q1 but I am unsure if we will have time so don't take this comment as a commitment.

Re external signing, just to clarify, you want two completely disjoint groups of users? One managed by Nhost Auth (and for which auth0 knows nothing about) and another one managed by Auth0 (and for which Nhost knows nothing about)? That should be doable, not today but it should be doable. Just keep in mind you mention you have some sync process, depending on what that sync process is for you **may** still need it (it depends on what you are syncing and why).

Basically the main difference between the two solutions is that idtokens creates a user in the Nhost Auth database and the proposed external signin wouldn't.

[ctrlemo]

Yes you nailed it right there in your comment.

---

In my case the syncing that I have setup from Auth0 to a table in Postgres is to have a user's account data from Auth0 handy. (Firstname, Lastname, Last login datetime, Total amount of logins, Last Password reset datetime)
With handy I mean for scenarios like when I make graphql queries on users data in Nhost Postgres, I can also easily return some of the users Auth0 account data together with the graphql responses to display on the Front-end reports.
This results in me NOT having to create any Hasura Actions and Nhost functions to query Auth0's Management Rest API's on the fly to get the additional users data. Which can result in slower graphql queries, because of having the additonal http calls.
Instead I am Upserting this data into postgres from an Auth0 Action right after a user log's in. Because in my case after the user log's in I don't really need the latest account data from Auth0 anyway. So another reason to upsert it upon login only and not make dynamic on the fly api request to auth0.

Of course this part may or may not be needed by developers. It depends on their project and needs. So I would leave the implementation user account data syncing up to the developers, because their project needs may very a lot.

Just adding more context to help Nhost team with defining the right implementation for this feature.