Hacker News Reader

Appreciate the educational back-and-forth between interesting companies in here!

Having just done a review of auth vendors (including FusionAuth + Auth0), I think your product addresses a much simpler use-case. FusionAuth and Auth0 support complex multi-tenancy setups and tie that into enterprise SSO providers, and all that's configurable on a per-customer/application basis with logical separation inside the auth vendor. I don't believe you support that level of complexity yet.

The nitty-gritty of auth does suck for most projects/early startups, but once you start selling to mid-size customers (B2B) they'll demand features that require what FusionAuth/Auth0/similar competitors offer.

Yet :)

Indeed, we're still catching up on feature-completeness, especially for the B2B world. In 2022 we will be tackling organization onboarding, SAML SSO, roles and permissions, subscription management, and authorization (as it relates to permissions and subscriptions). Still just getting started...

I'm old and now more of a team therapist than developer but i really want to get back to actually writing code and may take up svelte (based on the awesome discussion yesterday). I will be signing up for clerk.dev today, thank you for the post!

Having spent much of the past week wondering the same thing, I think I'm now in love with your product. Looking forward to giving it a try. Thanks for jumping into the page to tell us about it.

Hiya Colin!

Disclosure, I'm head of devrel at FusionAuth, as well as a co-worker of the author of the post.

We think there is value in separating identity in the way you describe for a number of reasons.

  * While this tutorial is about one app, that isn't usually how things work beyond demo land. In most places you have more than one application authenticating against FusionAuth (a couple of custom apps, OSS software like forums, COTS like Zendesk). In this case, isolating identity to a single component allows you to manage it centrally and to, if needed, bolster security.
  * If you use OAuth, you get access to a tremendous selection of libraries across different languages. Every language has an OAuth framework you can use. 
  * Developers can have portable skills. Sure, figuring out the Authorization Code grant can be a bit of a pain, but once you do it once, you can do it again and again.
  * By standardizing on OAuth/OIDC, you can move between identity providers. Yes, there are differences at the edges, but you'll have more flexibility than if you code to say, Clerk. This may or may not be worthwhile.

I haven't taken a close look at clerk, but I'm not sure how you handle the multi application setup. It is likely that both FusionAuth and Clerk are approaching the same problems in different ways (which is fine!).

If you want to see a take on how we think about authentication, the Modern Guide to OAuth is a great article to read: https://fusionauth.io/learn/expert-advice/oauth/modern-guide... particularly the "OAuth modes" section.

For multiple services, we've been seeing more and more services adopt JWT-based models for SSO. We have a Hasura integration where we'll generate the JWT necessary for authenticating queries: https://docs.clerk.dev/integrations/hasura

In general, we're pushing for more use of short-lived JWTs to sync identities between trusted parties instead of OAuth. We think this is preferable because it can keep sessions synced, while OAuth tends to result in independent sessions.

Admittedly, we do not run an OpenID Connect server on behalf of our customers yet. This is on our roadmap and will be added soon, and there are definitely some services that we can't offer first-class integrations with until that happens.

Your other point about "every language has an OAuth framework" is well-taken. Our initial launch used something proprietary and this was an issue, but we recently switched to spec-compliant JWTs to benefit more from existing libraries. Here's an example of our current, standard token:

https://jwt.io/#token=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18xcn...

When you say "JWT-based models for SSO" what do you mean? I'm a bit unclear.

FusionAuth works with GraphQL/Hasura as well, see this post from a community member: https://fusionauth.io/community/forum/topic/696/how-to-use-f...

> In general, we're pushing for more use of short-lived JWTs to sync identities between trusted parties instead of OAuth. We think this is preferable because it can keep sessions synced, while OAuth tends to result in independent sessions.

This is an interesting approach. Can you tell me more (or just point me to the docs)?

> Admittedly, we do not run an OpenID Connect server on behalf of our customers yet. This is on our roadmap and will be added soon...

That's great! I'm sure your customers will welcome the additional flexibility.