Live data from Hacker News

Show HN: Clerk – all of user management as-a-service, not just authentication

clerk.dev

141–150 of 234 posts

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#141

Earlier quoted context omitted.

Sure, because “do passwordless emails” is just a snap of the finger away, right? The point is that doing auth properly is hard. Sending an email might be easy, but creating and managing the session in a secure fashion is hard, even if you’re “just doing passwordless email auth”.

> Sure, because “do passwordless emails” is just a snap of the finger away, right? uh, yes? https://magic.link/ > The point is that doing auth properly is hard... it works just like password reset no? there's not much state with passwordless email auth as opposed to passwords.

This whole comment thread is about not outsourcing your user management stack to a third party and your intended suggestion is.... A different third party?

I don't think I understand exactly what your argument is.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#142
post #92

Earlier quoted context omitted.

Glad you chose cookies for this versus localstorage JWT tokens. Kudos for that.

Out of curiosity, why are cookies preferred to local storage ?

XSS attacks.

Also note that the cookies should be http only and with the secure flag

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#143

Earlier quoted context omitted.

So you hack apple's private forwarding email service right, how would one get in? I've even used G Mail's forwarding email for 6 years and I've never been hacked. If you're concerned about this just use a fake email.

You’ve gone off on a personal tangent about how I as a user can increase my security. The topic of discussion was you claimed passwordless security had no security issues and I pointed out possible security issues. An individual can mitigate them, but they still exist

> The topic of discussion was you claimed passwordless security had no security issues and I pointed out possible security issues.

But you claimed that the email can be hacked, I used an email forwarding service provided by google or apple.

So are you saying I can be hacked through this way, please provide evidence of this happening in a real world passwordless scenario.

> An individual can mitigate them, but they still exist

Again, I would be more convinced of real world evidence and statistics rather than theorising.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#144

Earlier quoted context omitted.

> Sure, because “do passwordless emails” is just a snap of the finger away, right? uh, yes? https://magic.link/ > The point is that doing auth properly is hard... it works just like password reset no? there's not much state with passwordless email auth as opposed to passwords.

This whole comment thread is about not outsourcing your user management stack to a third party and your intended suggestion is.... A different third party? I don't think I understand exactly what your argument is.

You said:

> Sure, because “do passwordless emails” is just a snap of the finger away, right?

And I showed it literally is.

The choice is yours to reimplement this authentication system, but in terms of "a snap of the finger away", You can do that, That is all.

I've done these type of systems before at scale and it took minutes to do (works just like a password reset mechanism) and it is very trivial.

In your original comment above, I think you are projecting this a bit too much.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#145

Have you considered offering an on-premise solution? Ideally a docker image you can easily stand up and point to a postgres DB. I can only imagine using this "for real" if I could actually store the users in a database I manage. The last thing I want is to introduce a new 3rd party single-point-of-failure.

Hey Diggsey, yes we have. We've deployed this way for one of our customers. We still need a better story on how to migrate from hosted -> on-prem/private clud, but we're working on it. Feel free to contact me: braden@clerk.dev

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#146
post #92

Earlier quoted context omitted.

Glad you chose cookies for this versus localstorage JWT tokens. Kudos for that.

Out of curiosity, why are cookies preferred to local storage ?

As the others said - XSS. Stored XSS can still be a vulnerability with secure cookies, but locally stored tokens are a dramatically easier thing to take advantage of as an attacker, as they can just exfiltrate the token and hit your APIs with it.

For web browsers, cookie-based auth solves a ton of browser-specific problems that history has spent a long time building up answers for.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#147
post #56

Earlier quoted context omitted.

Just wait until you find Userfront, which does the same thing for free until 10k users

Sometimes you get what you pay for. Personally I would not want my data managed by a company that doesn't even have a team page or mailing address (let alone security details) and appears to be using a Bootstrap template for their website.

[deleted]

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#148
post #80
post #64

Earlier quoted context omitted.

sort of like "economic moat"...yeah I can definitely see why AWS is quickly becoming a monopoly. 10 years ago? I might have used Clerk, I guess I'm not seeing what the value proposition here is to me its: Do I trust a new service or continue with one of the most trusted service from AWS?

Yeah, definitely. It's a phenomenal virtuous cycle for AWS. I think that honestly, the biggest sell for a lot of newcomers is gonna be "you don't need to know AWS!" -- in my (very limited!) experience, if you want to do X with AWS, you're gonna need to learn how to do W, Y, Z, and maybe A and B with AWS too.

Another selling point is if you are not using AWS infrastructure at all. If you are trying to build a service that you do not want to utilize the tech giants AWS or Google, it’s a selling point.

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#149
post #138

So, first, congrats on launching your product. :) Personally, I don't have a need for it, and if I did, I'd be very reluctant to use a proprietary service, but I'm sure there are companies out there who will be happy to use you. Good luck! ------------ That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of servic…

Check out the [org](https://www.ory.sh/hydra/) family of projects

Re: Show HN: Clerk – all of user management as-a-service, not just authentication

#150
post #138

So, first, congrats on launching your product. :) Personally, I don't have a need for it, and if I did, I'd be very reluctant to use a proprietary service, but I'm sure there are companies out there who will be happy to use you. Good luck! ------------ That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of servic…

Check out the [org]( https://www.ory.sh/hydra/ ) family of projects

I second ory, that's pretty much a solved problem in my book.

Fast self contained binaries, easy to interface with Kubernetes.

Adding some UI around them and managing them via api is nice enough.

The only incognita is whether they're going to handle scaling (I hope I'll have this problem one day).

Hydra is for OpenId though, I'd point to Kratos + Oathkeeper.

Post reply on HN