6 ms·

Disclosure: founder of clerk.dev I'm interested in why FusionAuth chose OAuth to share identity between localhost:${serverPort} and localhost:${fusionAuthPort}

Disclosure: founder of clerk.dev I'm interested in why FusionAuth chose OAuth to share identity between localhost:${serverPort} and localhost:${fusionAuthPort}? Auth0 does the same, and it's always struck me as misplaced. OAuth makes sense to me between two distinct parties, but the architecture here treats FusionAuth and the application as a single party. Meaning, when a user signs in through the FusionAuth form, they're actually signing in to the application. That's not true of Google OAuth - if a user signs into Google, they're not automatically signed into every service where they've ever clicked "Sign in with Google". We moved away from this model because it also makes it really hard for FusionAuth to manage the user's session on the developer's behalf. You can see in this writeup that the developer is asked to pull in express-session to manage the user's session on their own. Our mindset is: since Clerk is same-site to the developer's server, we can manage the user's session on behalf of the developer. When dev's use clerk, they don't need to think about cookies or sessions at all, except to the extent that lifetimes are configurable in our dashboard.

chasd00 5y ago
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!
yodon 5y ago
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.
mooreds 5y ago
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-to-oauth/ https://fusionauth.io/learn/expert-advice/oauth/modern-guide... particularly the "OAuth modes" section.
- colinclerk 5y ago
  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 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=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18xcnJVREpyU0tDVlpiVWVnY2tmcWlrWFdQNzAiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MzY3MzAyMDQsImlhdCI6MTYzNjczMDE0NCwiaXNzIjoiaHR0cHM6Ly9jbGVyay41bWFwNi44ODFqbS5sY2wuZGV2IiwibmJmIjoxNjM2NzMwMTM0LCJzaWQiOiJzZXNzXzIwcDhQVm0xdE80NzJVd1had3htbkxDZXV2UiIsInN1YiI6InVzZXJfMjBwOFBVMTNwTWl6d1p2TnlNdVRrZEtEeTNSIn0.ZuOIFEnLQKjroGQrmuVc1BaeLHn23Gv4sRrQeoQ6BWDcvpU31q7a3WYxVNnfr6AOppthZ1ZEJMtlZsiOQ_AGvVgiMJBi9MtmlOFOk8ZRHfgADNouYyjUQJLEI_3AV9nY5VhUntG4vTDib7-7dA2DemhV7YVc64xJznaq-SvshdFftr7nVueB-28gBQSUFVkhcX_43m_AsjY9e_KMh9Le7FwgHCBlKRMH0cZMQlDAjY9yp1oD9ydrw41xLVwBLdex1SdMjH6r7LxBtv8dm2C2nRNlQkybUcsswYxgVF_w0DBGB6ViCN2xrgiC9qEfSQaSkjkY3KpEG5FeBMBbSqADBA https://jwt.io/#token=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18xcn...
  - mooreds 5y ago
    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-fusionauth-jwt-token-and-claims-with-hasura-graphql-to-authenticate-graphql-requests 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.
BowBun 5y ago
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.
- colinclerk 5y ago
  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...

chasd00 5y ago

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!

yodon 5y ago

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.

mooreds 5y ago

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-to-oauth/ https://fusionauth.io/learn/expert-advice/oauth/modern-guide... particularly the "OAuth modes" section.

colinclerk 5y ago
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 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=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18xcnJVREpyU0tDVlpiVWVnY2tmcWlrWFdQNzAiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MzY3MzAyMDQsImlhdCI6MTYzNjczMDE0NCwiaXNzIjoiaHR0cHM6Ly9jbGVyay41bWFwNi44ODFqbS5sY2wuZGV2IiwibmJmIjoxNjM2NzMwMTM0LCJzaWQiOiJzZXNzXzIwcDhQVm0xdE80NzJVd1had3htbkxDZXV2UiIsInN1YiI6InVzZXJfMjBwOFBVMTNwTWl6d1p2TnlNdVRrZEtEeTNSIn0.ZuOIFEnLQKjroGQrmuVc1BaeLHn23Gv4sRrQeoQ6BWDcvpU31q7a3WYxVNnfr6AOppthZ1ZEJMtlZsiOQ_AGvVgiMJBi9MtmlOFOk8ZRHfgADNouYyjUQJLEI_3AV9nY5VhUntG4vTDib7-7dA2DemhV7YVc64xJznaq-SvshdFftr7nVueB-28gBQSUFVkhcX_43m_AsjY9e_KMh9Le7FwgHCBlKRMH0cZMQlDAjY9yp1oD9ydrw41xLVwBLdex1SdMjH6r7LxBtv8dm2C2nRNlQkybUcsswYxgVF_w0DBGB6ViCN2xrgiC9qEfSQaSkjkY3KpEG5FeBMBbSqADBA https://jwt.io/#token=eyJhbGciOiJSUzI1NiIsImtpZCI6Imluc18xcn...
- mooreds 5y ago
  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-fusionauth-jwt-token-and-claims-with-hasura-graphql-to-authenticate-graphql-requests 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.

BowBun 5y ago

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.

colinclerk 5y ago
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...