colinclerk

> but less hard than it ever has been before

I have a very vested interest in this (founder Clerk.dev) - but the exact opposite experience is what led us to start Clerk.

Auth was easy when it was just email verification and choosing the right hashing algorithm. I used to pull Devise off the shelf and get it going in 30 minutes.

But these days, the simple solution is far from complete. I grew most frustrated trying to setup the rest...

- Single sign-on / Oauth with proper de-duping so users can always sign in regardless of how they signed up

- 2fa so users can better secure their accounts

- Integrations with a leaked password corpus (haveibeenpwned) to prevent credential stuffing attacks

- Active device tracking and remote session revocation

You can launch without these things, but it's definitely impacting your overall security and the conversion rates through your sign up and sign in flows.

Yes, unfortunately you've picked the wrong issue to be scared about.

The CSRF attacks you're describing have been solved by browsers with the SameSite attribute on cookies. If you set SameSite=Lax or SameSite=Strict, cookies will not be sent with requests originating from a different site.

In choosing localstorage over HttpOnly cookies, you've put yourself at greater risk in the event of an XSS attack (meaning, an attacker running their javascript code on your own domain).

When your users' session tokens are in localstorage, an XSS attacker can exfiltrate the tokens from localstorage, and potentially transfer them off your site to their server, where they can then cause more havoc.

HttpOnly cookies prevent this problem because the XSS code can't access the cookie value, so they can't be exfiltrated and transferred elsewhere.

I recently wrote a little bit about this here: https://www.clerk.dev/blog/how-httponly-cookies-help-mitigat...

Your application should certainly have some resolution to an account being hacked or a session token being stolen.

No expiry and no denylist means an attacker can cause problems until you patch your code.

I think the edge compute trend is cycling developers away from CORS again.

The old server-rendered frameworks (rails, django) never really needed CORS because frontend and backend were on the same origin.

Then lots of CORS issues cropped up when we started putting React frontends on a separate subdomain from the backend.

But these days, frontend and backend are being pushed onto the same origin again by running compute (or a reverse proxy) at the edge. Next.js is a good example that has baked this practice into the framework itself.

It used to be, and that's why web frameworks included a CSRF token with all write requests. Without the CSRF token (which a third party couldn't have), the write would be stopped.

In modern browsers, the CSRF token isn't necessary anymore as long as the cookie's SameSite policy is set to Lax (the default) or Strict. Both will stop the cookie from being sent with a third party form submission.

The SameSite cookie policy doesn't offer fine-grained control like CORS. So, if you want to allowlist cookies for certain third-party origins but not all, CORS would be a better option.

In practice, most sites want to prevent all cross-origin requests and SameSite is easier.

And in more recent practice, Safari and Firefox are blocking third-party cookies by default, so it's pretty rare to see a setup leveraging CORS for fine-grained cookie access.

This is what inspired me to look into true JIT: https://news.ycombinator.com/item?id=26731816

I've started investigating whether a truly "just in time" variant of Tailwind is reasonable. It's almost like a CSS transpiler - converting tailwind classnames to their CSS form.

You'll probably always want AOT for the "critical css" in the first load, but afterward, JIT might be reasonable.

At a minimum, it should be feasible. You can override Prototype's appendChild, replaceChild, and insertBefore to grab classnames and generate CSS before the DOM is updated. Everyone will tell you this is insane, but it seems to work.

But it's unclear if this leads to something "better" than the AOT solution. It feels like code golf: will the transpiler have less bytes than the CSS generated by a pure AOT solution? The tailwind folks have come up with a really dense way of expressing verbose CSS, so I think it's possible!

No affiliation to Tailwind. Just playing on weekends.

Sorry about that, I think I cluttered my response by talking about the client-side use case.

Does anybody use ETL-for-marketers tools to extract User data from one source, then load it into Stripe as Customer objects?

I don't think it's common. We mostly see developers creating Stripe Customer objects themselves in their backend.

If I understood your original question correctly, you were asking why ETL tools don't do this? I think it's because these tools are deliberately capable of working with fuzzy data streams, so it at least feels weird to start using them for secure actions. Their security model may also make it dangerous to try.

---

Somewhat aside: Authenticating actions from the client is most-easily solved by signing JWTs. Tools like Hasura are doing this in the wild, though it isn't too common among third-party APIs yet. Another close example is Intercom, which asks you to use a non-JWT signature to pass in user data: https://developers.intercom.com/installing-intercom/docs/ios...

Because they don't know confidently which user is logged in. A lot of the marketing tools rely on insecure signals, like a userID passed directly from javascript.

If you want to trigger actions rather than observe them, you need a secure way of authenticating those actions. That's why Clerk does session management :)

Third party integrations

My take on this is a little different. (Disc: I'm a cofounder of Clerk which is also in the space)

I think Okta will try to build "Okta for Customer ID"

When people think of Okta, they think of it as a tool to help employees securely access third-party SaaS vendors.

That same problem exists for Customer Identity, but it looks a little different. Instead of setting up SSO for SaaS, developers are writing code to pass their customer data into tools like Stripe, Intercom, Salesforce, Segment, Mailchimp, etc, etc.

This is redundant work that a centralized Customer identity provider has the potential to alleviate.

I don't really think Auth0 is well-positioned to pull this off, and that's part of why we started Clerk. But considering Okta has that playbook in it's DNA, I wouldn't be surprised if that's what they're attempting.

Thanks for the mention :)

Come join us! We're building similar react components for creating and managing organizations, including a self-serve way for IT admins to setup SSO for their org.

It's a different attack vector.

Session tokens should be stored in an httpOnly cookie, so they're not accessible to a third party script.

CNAMEs could absolutely lead to leaked session tokens, but website owners should already be somewhat accustomed to hiding cookies away from third party subdomains. These days, lots of third party services run on subdomains... blogs, status pages, email click trackers, support desks, etc.

Hey Raphael, Colin from Clerk here. Alex popped into our Slack and we've been looking into whether an integration is possible.

We haven't found a way to wrap the entire WeWeb application with a <ClerkProvider> component (which is a React context under the hood and informs our other components). Is that possible?

Or, in lieu of that, is there a way to hook Javascript into the rendering lifecycle of a page/component. Behind our React components is just vanilla JS, so if there were a way to control rendering based on window.Clerk.user being null, we'd be off to a good start for simple authenticated pages. (You can play with window.Clerk.user in console on https://accounts.clerk.dev to see how it works)

Would love to collaborate on an integration! You can reach me at colin@clerk.dev

Great privacy-focused launch, Firefox!

If anyone wants to see these protections in action, www.clerk.dev leverages the Storage Access API in development mode - where we need to share session data across localhost and a clerk-owned domain.

With this launch, developers are now prompted to explicitly allow third-party cookie access in Firefox.

(In production mode, the prompt isn't thrown because our cookies are set in a first party context.)

Hey Grinich! Yup, that's me :) Small world indeed.

The copy was updated to say:

> Our prices are based on your Monthly Active Users (MAUs) and not your entire userbase, so you only pay for logged in users who interact with your website during the course of the month.

Does this help clarify? Sorry for the confusion.

Yes - we're hiring now to help get this built! https://apply.workable.com/clerk-dev/

Thanks for the question! Right now we only have an SDK for React, but under the hood that SDK is a thin wrapper over Vanilla JS.

What other frameworks would you like to see prioritized?

Thank you for calling out the headers. We'll work to resolve right away.

And agreed on the CDN JS. We'll move these assets to the customer's domain.

Completely agree with everything here.

It's not documented yet, but our frontend components leverage an API that was built with the expectation that some developers won't like our designs, or will need something custom we can't accommodate.

In those cases, using the API directly should offer the flexibility you need.

Hey all - looks like there's a lot of confusion on the pricing model here. That's our fault, sorry!

The free plan does not include 2-step verification, and that was the reason for the increase in the paid plan.

We'd love some feedback on how you'd like to see the free plan constructed. What would be most helpful for getting you started with Clerk?

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

Hi Colin!

On your backend, Clerk gives you a stable User ID for each user. You're free to use it as a foreign key in your database as you normally would. (clerk.dev runs on clerk, and that's how we do it internally)

We only have a Node SDK so far - here's a guide on retrieving the User ID from your backend: https://backend-docs.clerk.dev/quick-starts/next.js-api-rout...

Soon we will launch a way to add custom attributes to the user object, as well as management of those attributes in the UI if desired. Things can get a bit murkier there, but those features will always only be opt-in.

Definitely! We've found that developers want to apply subscriptions against either Users or Organizations, so first we're planning to build out Organization management first (create an org, invite members, setup SAML auth, etc).

Subscription management will follow sometime after, and will probably look like a Stripe integration that automatically creates Stripe Customer objects for your Users and Organizations. Is this along the lines you're thinking?

Thank you! Resolved.

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.

Hi HN - We couldn't be more excited to launch Clerk and help developers solve all of user management.

It's been quite a journey to reach this point, with over a year of iteration on the developer experience before we found something developers love. Using Clerk will enable you to spend more time on your application, and less time worrying about the ever-growing list of user management concerns.

Our team is listening in this thread and we're happy to answer any questions.

I'm surprised about the timing.

The serverless/edge technologies becoming available at CDNs are making it easy to imagine "automatic push" could come soon.

Any chance there are folks from Vercel or Netlify here and can shed light on why push hasn't been implemented in their platforms (or if it has)? At first glance, it seems like Next.js in particular (server rendering) is ripe for automatic push.