Netlify identity lock-in

Lockin might be too strong of a word, but my point is that it is difficult to spin up other parts of your api outside of netlify’s function and still being able to verify user’s requests.

I’m trying to help improve the serverless deployment, and as part of that I want to migrate my own project over to severless to have skin in the game as I work on it, though I’v hit a roadblock with netlify identity, because normally when using netlify functions with their identity service they have a magic layer that adds the users info to the event context (if it’s valid based on the authorization header/token).

When sending requests to infrastructure outside of the netlify functions than you would need to verify the token yourself, however there’s no way to do that because netlify does not expose the secret they are using for your identity instance.

Chris Biscardi has a solution, but it’s an async one based on making a call to the identity service for each request. Seems like a last resort solution to me.

Puts me in a bit of a pickle since I’m already using the identity service.

Anyway just wanted to document what I’ve found recently.

Edit, secret can be set, see: Netlify identity lock-in - #6 by Irev-Dev

This is the exact reason I created dbAuth! I couldn’t use Netlify Identity without deploying there, and then I spent an afternoon trying to configure Auth0 and gave up. :frowning:

1 Like

I believe lock-in is exactly the correct term. It’s great for tutorial simplicity, but I don’t recommend using it for much beyond hobby app for this reason.

I’m impressed with Clerk in terms of set up simplicity. It might be a good tutorial replacement to that end.

And of course dbAuth if you’re comfortable with self hosting.

Otherwise, top three options by my count are Superbase, Firebase, and Auth0. (Note: @chenkie worked at Auth0 and @giannelli.tech is there now)

Lastly, don’t be intimidated about porting. Relatively little logic will need to be swapped. And you can get your users migrated. Just have them create a new password at next login (and/or email notice, etc).

2 Likes

Besides making me a little nervous, I’m really tempted to make the switch to dbAuth!

I really like the idea that having a staging db means I’ll get staging auth for free.

I read through some of the docs this morning and one question I have is: because I’m interested in allowing third party identity providers (github login etc) would it be possible to extend dbAuth to allow this, if so do you have much of an idea of what might be involved?

Thanks David, I think port is likely at this point :slight_smile:

1 Like

Follow up,

The secret can be set, but not through an identity setting? :confused:

Instead it’s an access-control feature, which is a paid feature. Still enough for me to want to move on.

1 Like

I haven’t tried it, but there’s a thread about extending dbAuth with OAuth here: Combining dbAuth + OAuth2

2 Likes

Sorry for the radio silence, this had me thinking enough that I put together a proof of concept for adding a github login to dbAuth

I think the the way I’ve changed dbAuth makes it a generic solution, but it’s also pretty rough at this point.

3 Likes