Just wonder price wise, if I signed up for the free and then switched over to paid it would be $249 for 5000 MAU.

Compared to say Auth0, which would be $114 for 5000 MAU.

The only difference is profile, and Auth0 mostly covers it by allowing you to easily store metadata.

I am not sure I understand what makes Clark worth 2x Auth0?

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.

Just looked it up. I don't know how I've never come across this. Reading the docs quickly it seems like this is cheaper and easier/more intuitive to set up than any other auth service. Will definitely be trying it with my next project, thank you.

I tried very recently to research all the "auth0 alternatives" and that project never came up.

Another question, I don't see any mention of security. You are in complete control of our users/profiles and their login credentials and there is zero mention of how secure that data is.

Hi dubcanada,

Thanks for your questions! It's good feedback that there's no security documentation up yet. We have a lot more content coming live in the next few weeks - but let me try to hit some of the most important points:

* Session management is handled with secure, httpOnly cookies. We have you set a CNAME in production so we can set cookies in a first-party context (SameSite=Lax). * Cookies are scoped only to domains that require authentication data. If your backend is on api.example.com and you're running hosted Wordpress blog on blog.example.com, Wordpress won't receive your session cookies. * Passwords are bcrypted * All frontend-facing endpoints have CSRF protection enabled

Please let us know if there is anything specific we can help clarify. We've gotten into the nitty gritty so there's a lot to document, and it would be great to understand what areas to surface most prominently.

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.

XSS attacks.

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

Any JavaScript on the same origin can read localstorage IIRC.

Your HIPAA status will be important for the increasing number of health related apps out there that would probably use a service like this.

SOC 2?

Not yet. We plan to pursue SOC 2 as we build out Organizations, since it's a clear requirement in a B2B context.

And B2C. You really ought to provide more transparency around your current security practices on your site. I do not see why someone should implicitly trust your service without any assurances, guarantees, descriptions, whitepapers, etc.

Here's a good reference: https://trust.okta.com

Bcrypt should be replaced by Argon2

Agreed - but I would also be interested in knowing if they hold cybersecurity breach insurance. That way, users could actually submit a claim for major issues.

I forget what this effect is called. Every once in a while a new service comes along that tries to compete with Amazon and there is a huge cost of entrusting the new entrant.

I think I've seen the term "trust moat" used before, which I like for describing this effect.

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.

it's a tough sell imho because AWS has a learning curve but I feel like most devs are okay with being enmeshed for building scalable and secure systems on top of it.

AWS moves so quickly I think it would be a disadvantage to rely on a smaller, unknown 3rd party that tries to replace itself as AWS.

If I try Clerk for an application but decide I’m not happy with it, what is the process for moving my user management away from Clerk and into my own system?

Seems like an amazing product! One thing that would be amazing for you to tackle is support for devices, services, etc. Things that are not driven by a user and do not have a browser. I've worked at a few IoT companies and authentication is always a massive pain in my ass. SSO for web pages is annoying, authentication for 3rd party APIs or devices that need to sit in the middle of nowhere and don't have people to "login" on them is a whole other layer of pain. I'd love if you had a solution in that area.

Thanks for sharing! Will consider it for future projects.

It’s nice to see that there’s an MFA option, and login notifications coming soon. I build this into my small projects too - even if unconventional - because I like to be warned about unusual activity on my accounts. Last thing you’d want is someone taking over a super user or staff account without anyone noticing.

Just a small note: would be nice to have a page describing your security practices.

Congrats on the launch!

I'd suggest making it very clear in your docs whose data you're managing, and (assuming it's all the customer's and you don't lay claims to it) how would portability work. I wouldn't want to use this without a very clear understanding of what I'm locking my customer base into.

Are you offering any security benefits?

What security is there against malicious insider threat? (Eg can you / people at Clerk impersonate any of my customers on demand? Is there auditing/accountability for such activity?

Is this something that sites with crappy roll-your-own user management would be advised to migrate towards, and if so why?

How close are you to adding billing to this? And do you have a public road map anywhere?

@colinclerk, the "Explore documentation" link on the front page is dead.

Thank you! Resolved.

So is it the same as Login with Facebook or Google? Google/Facebook/Clerk manages the GDPR (do you? that is 300% added value for a business) and the app can focus on the data?

Is your main added value that you are not Facebook/Google?

GDPR and CCPA are important issues for this sort of 3rd party PII management stuff.

I'd be _very_ hesitant to use this without some very strong guarantees that legal won't come breathing down my neck because I can't point them to a contractual guarantee that we will be complying with those (and similar rules from other jurisdictions).

I lose enough sleep worrying about PII that I store in databases I manage. Farming that responsibility out to a 3rd party does not fill me with joy, it raises instead lovecraftian levels of horror about what I'd tell a judge about how I ensured an EU citizen's rights to have their data expunged from my auth/userprofle system...

If you don't mind me asking, What data do you store that you think is PII?

- email address

- name

Quite often user profile data as well. Job title and company in a bunch of projects. Sometimes profile pics. Social media accounts. Location or address details - sometimes just coarse location like "Sydney", sometimes exact delivery addresses - sometimes geolocation co-ordinates used for geofencing or smart defaulting (Apple's new coarse geo location is a good thing here, but I wouldn't want to be the test case in court about whether or not that's PII). Phone numbers (if needed, like for SMS alerts or shitty 2fa verification requirements I can;'t talk people out of).

Where I cone from (.au) even an ip address is considered PII under our Privacy Act if it's linkable to another identifier - an ip address on it's own is not PII, but an ip address and an email address makes the ip address into PII as well as the email address. (It's unclear, but this likely includes storing a "last login date" in your email-containing database table that "could" be correlated to a login api call with an ip address in your log files, even if you are not actively doing that.)