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.