colinclerk

Clerk cofounder here - appreciate the feedback and forwarding to the mobile team!

Clerk cofounder here: I hope this isn’t a Clerk stakeholder! It’s definitely misaligned with our culture around not speaking about competitors and instead playing our own game.

I wrote the tweet that Brandur quoted...

I think the bigger shifts are that developers use Checkout more, and complete more admin tasks in Stripe's Dashboard. By providing end-user UX (for both customers and backoffice), Stripe has reduced the API surface area that most developers need to consume. These changes end up having no impact on them.

Appreciate that. We have many thousands of apps like yours on the platform, and I’m glad to hear the free plan is working for you.

Forgetting about your auth provider is indeed the dream!

Cofounder of Clerk. I agree - our pricing has been significantly reduced since this was written (partially in response to this post)

We do intend to build more products, but if you're using us for pureplay auth we shouldn't cost 1% of revenue at scale.

(As far as I know, we don't cost 1% at any scale, except very early startup days pre-revenue who opt not to use our free plan.)

Fun!

I just put our logo up. It took me two tries before it took, so maybe a twodollarhomepage :)

What's the stack?

Hey - cofounder of Clerk here

Glad we were able to mitigate this one for our customers, but have also been a bit surprised this vulnerability hasn't been generating more chatter.

tl;dr: if you use Google OAuth, any XSS on your site can likely be chained into a long-lived account takeover. In a roundabout way, it works around the protections afforded by HttpOnly cookies.

You can mitigate by always redirecting to a URL with an empty fragment (#) if your oauth callback URL experiences any failure.

Answering 2 first because it's easier: Yes.

1. It's a great question and we're still learning the answer. But, I believe the approach is ~95% compatible, and the last 5% just needs tweaking on the margins vs a major overhaul. Let me try to explain...

First: SSR definitely makes the framing of "frontend api" vs "backend api" very confusing. So ignore that, and think of it purely as "api authenticated with a session token" vs "api authenticated with a secret key."

I think authenticating via session token is the key to enabling faster development with Clerk than tools like Auth0 (or even Stripe/Twilio/etc). The reason why is that it shifts the problem of _authorization_ from our customer's backend to Clerk's backend.

As an example, consider a user updating their email...

In the past, you would build a frontend for collecting their new email, send it to your backend, ensure that the user is updating their own name (the authorization step), then forward the update along to your account system (Auth0, your own database, whatever).

With Clerk, you build a frontend for collecting their new email, then send it straight to Clerk to handle the update with the user's session token. We are responsible for ensuring the update is to the users own account, and there's no requirement to hop to your backend to relay the secret key.

In the end, that hop to the backend and authorization check is responsible for a lot of the "clunk" that Clerk eliminates. And ultimately, SSR doesn't change our ability to make things easier – we can authenticate our API with a session token just-as-well during SSR as we can from the frontend.

This feels like a paradox, right? A session token has such limited power compared to secret key, so surely it can't be used to build an easier API. But in practice, confidently knowing which user is making the request is necessary for shifting the authorization step to our service.

I'd add that this idea isn't particularly novel. Stripe Checkout depends on a CheckoutSession object, which you initialize by passing in the active user's ID. So there, you see that Stripe having the active user's ID enables them remove a ton of steps for building a checkout. Implicitly, under-the-hood Checkout relies on an API that uses a session token for authentication.

We just took the idea one step further and are exposing the API, instead of only using it to power a single, fairly rigid UI. With Clerk, developers can use React Hooks to build their own UI.

---

Now, regarding the 5% that we still need to figure out. It pertains exactly to the currentUser() and currentOrg() functions you're calling out. Those are compatible, but they require some extra thoughtfulness.

As an example, Clerk's User object has a field called "privateMetadata". From the backend, it's completely okay for currentUser() to return this private data, but Clerk needs to make sure it doesn't leak to the frontend. That creates some oddities - the User object on frontend is different than on backend, and I don't think we've really nailed the ergonomics / education on this part yet. But it generally feels like a solvable problem.