Hacker News Reader

Comment by colinclerk | Hacker News Reader

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.

View on HN

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

That’s how I think of Auth0+Duo.

I think of Okta as the more expensive, less flexible, slower moving, harder to deal with competitor to them.

> But considering Okta has that playbook in it's DNA, I wouldn't be surprised if that's what they're attempting.

I'm sorry; Okta has which playbook in its DNA?

Third party integrations

Why aren't all the existing products in ETL-for-marketers space already the answer to the question you pose?

Most companies have a users table, and there are a ton of products that can, without code, ETL a users table into all sorts of tools. There's no redundant work -- in fact, for developers there may not be any work to do at all?

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 :)

Let me make sure I understand you: I think you're talking about accurate attribution of clickstream analytics to particular users, in the face of spoofed data from clients?

And then, connecting the dots a bit, spoofed clickstream events could trigger some sort of marketing campaign event or other "action" that can become a vector for security issues, such as Eve figuring out what Adam has in his shopping cart by manipulating a cart-abandoned campaign to go to Eve's email instead of Adam's?

If so, this is usually addressed by server-side analytics events. I fail to see any mechanism by which this could be solved client-side, nor any useful way for any vendor to make this process meaningfully easier. Analytics events are basically as easy as console.log with most vendors.

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...

Reply on news.ycombinator.com