[HN Gopher] Show HN: Clerk - all of user management as-a-service...
___________________________________________________________________
Show HN: Clerk - all of user management as-a-service, not just
authentication
Author : colinclerk
Score : 250 points
Date : 2021-02-08 20:25 UTC (2 hours ago)
(HTM) web link (clerk.dev)
(TXT) w3m dump (clerk.dev)
| rexreed wrote:
| The pricing model has me confused:
|
| 1) Pricing is free up to 5,000 MAU
|
| 2) But the next pricing grade starts at 1,000 MAU for $49/mo +
| $0.05/MAU additional
|
| so if you have 5,001 MAU you take a big leap from $0 to $249/mo
|
| Is there a reason for that huge bump? Why doesn't the first pay
| tier start at 5,000 MAU?
|
| And how is MAU even calculated? Like, aren't all users in the
| system active users? Or are you able to have a bunch of unactive
| users in the system as well not counted?
| rnotaro wrote:
| I guess the pricing is more feature-based than MAU based.
|
| The professional pricing have "Two-step verification" and "No
| visible Clerk branding".
| ignoramous wrote:
| I feel the same: The upper tier pricing is a bit aggressive
| even if free 5000 MAUs is a good "hook" (more than sufficient
| for most upstarts).
|
| I've been meaning to evaluate keycloak.org and userbase.com,
| two radically different open source user management layers.
| Especially, userbase which seems to have a much attractive
| pricing for their hosted option.
|
| Besides, user management is something I'd like to rid if I can,
| and instead rely on anonymous / decoupled (passwordless?)
| identity layers like human-id.org and gazepass.com
|
| Cloudflare's OPAQUE is another enticing (zero-password) tangent
| in all of this, but they warn folks to not build identity
| systems using it, yet.
| kilburn wrote:
| Typically MAU means "users that logged at some point during
| that billing month".
|
| That is, when you are billed based on MAU you don't pay for the
| number of users in your database, only for the ones that
| actually use your app/service/whatever.
| rexreed wrote:
| Typically, that makes sense. Specifically, there's nothing on
| the website to indicate that is how they calculate MAU. The
| website is missing this critical bit of detail to inform
| would-be buyers.
| thrwaway2020aug wrote:
| I just updated the copy 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 about the confusion.
| colinclerk wrote:
| 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?
| zwayhowder wrote:
| For me to take a company seriously MFA must be in all their
| plans. MFA is not an enterprise hook for upsell, it is a
| fundamental requirement for any online service these days.
| wasd wrote:
| mau usually means logs in once during the month, if you have
| 20% mau that's 25k registered users. $250 / mo to manage a site
| with 25k users doesn't seem that bad.
| grinich wrote:
| I'm the founder of WorkOS
| (https://news.ycombinator.com/item?id=22607402) which is sort of
| close to this so wanted to share a thought or two.
|
| WorkOS has taken the alternative design of ONLY doing
| authentication and explicitly not user management. This is a
| subtle but I think super important distinction so figured it
| could be useful to share why in this thread, especially for
| developers looking at auth solutions and thinking about their
| app's architecture.
|
| Essentially in the market right now there are a bunch of user-
| management-as-a-service solutions (Auth0, FusionAuth, now Clerk)
| and all of them have a similar design. They provide hosted auth
| UIs and they "run" your user database. This gives them control of
| the identity layer of your app, and they are the "source of
| truth" for users.
|
| This has some benefits (e.g. centralized admin) but in talking
| with developers, we actually found there are huge drawbacks which
| are not initially obvious.
|
| The user database sort of the data holy grail. It's arguably the
| most important and sensitive data your app has. From a UX
| perspective, the sign-in UI is the "front door" experience. It's
| the one feature that literally every user touches.
|
| In OP's post, they write:
|
| _" Best of all, the components will automatically update as our
| team optimizes their design, develops new features, and adds
| support for the latest in account security."_
|
| We found this was the LAST thing developers want. There are
| plenty of open source sign-in components (Tailwind, etc) but with
| Auth0/Clerk/etc. you never get full control over the UI. It's run
| by a 3rd party which may introduce random new features at any
| time. It's giving up a huge amount of control, both UI/UX and
| strategic. Plus you're always in the "uncanny valley" of design,
| where your auth screens feel slightly different than the core app
| experience. IT admins have trained users to avoid these sites
| because they are typically phishing attacks. Not good.
|
| Even with all this, perhaps the biggest downside for developers
| is a longer-term issue: you get locked-in. If down the line you
| end up wanting to run authentication through an unsupported
| provider, too bad, you're stuck. This is how Auth0 gets you.
| Developers integrate early, all the users are in Auth0, and then
| it's too difficult or dangerous to migrate out later. You're held
| hostage. And this is when they raise prices like an
| authentication racket. ( _" You've sure got nice app here. Would
| be a shame if something happened to it..."_ etc.)
|
| Obviously biased as I've founded a company in this space, but I
| think we've solved a lot of these issues with WorkOS, allowing
| for maximum flexibility with powerful authentication APIs while
| ALSO enabling developers to fully control the user database. It's
| been a super hard thing to get right and I should really write a
| longer blog post in itself. But just a forewarning to app
| developers: be careful where you store your user data.
|
| PS: A misc secret for the HN crowd, we're actually launching
| 2-Factor Auth APIs tomorrow. ;) Zoom link here for the stream:
| https://lu.ma/workos-winter-release
| grinich wrote:
| Also colinclerk are you Colin Sidoti? If so I was a few years
| ahead of you at MIT and I think we totally we met a few times
| around when I was graduating. Small world! :D
| type_Ben_struct wrote:
| Looks great and I can see a lot of value in this having been
| disappointed myself with how much is left to the developer with
| services like Auth0 and Okta.
|
| Could you expand some more on the team behind this? As this
| service would be a critical part of any application relying on it
| for authentication I'm keen to know about the size of the team
| supporting it.
|
| Do you offer an SLA and 24/7 support?
| faeyanpiraat wrote:
| I'm even hesitant to trust Auth0 for this, why would I trust a
| new company?
| taytus wrote:
| This is my question as well. It's an honest question and
| hopefully someone can educate me.
|
| Why would anyone trust a third party with what is the most
| important asset, their users?
|
| Thank you in advance.
| camhart wrote:
| Most of the auth platforms I've used allow ways for you to
| migrate users off of their platform. You'd want to make sure
| at minimum you have their email address, but worse case
| scenario you'd require all users do a password reset
| essentially when you switch to the new auth provider. That's
| a horrible experience--but it's still an option. Better
| options actually allow you to migrate the user over as they
| login. You'd need to keep the "old" auth service around for a
| while though until you close the door on migrating.
|
| There's also an argument to be made that companies like this
| _could_ (certainly not guaranteed) employ security experts
| and have better implementations (through libraries) as a
| result. Those implementations _could_ (if updated
| appropriately), yield a more secure auth solution. In that
| regard, going with a third party, who has expertise, could be
| "better".
|
| Also, unless you're going to host your database that stores
| user data on prem, you're likely trusting a cloud with it.
|
| If I missed the point of your question I'm sorry. Did my best
| to answer. I have no relation to any of these services, other
| than I've used some at times throughout my career.
| mooreds wrote:
| Hiya,
|
| First off, full disclosure: I don't work for Clerk; I work
| for a competitor which offers overlapping functionality,
| FusionAuth: https://fusionauth.io
|
| I think a sibling comment laid it out well. It's a tradeoff.
| You are giving up some control over how your users are stored
| for significant acceleration of functionality. We've had
| customers say we saved them 1-2 person months of time in
| initial build, never mind ongoing maintenance.
|
| Would you build an app using a database managed by someone
| else? Isn't data a crucial asset? Some call it the new oil,
| I've heard. Yet lots of people choose to use an outsourced
| database provider. Auth is more user facing than a database,
| but if you can get the data out, what's the difference?
|
| That said, you should pick your own comfort level. Other
| options include self hosting (there are commercial and OSS
| solutions which you can run on your own hardware).
|
| You should also have a frank conversation with any providers
| about their security posture (sounds like the Clerk folks are
| going to add some docs to their site about this, which is
| great.)
|
| Another consideration: you want the ability to export your
| users should you want to move services. People who aren't
| self hosting with FusionAuth can get a database export from
| us, for example, if they want to migrate.
| kache_ wrote:
| It's much more lucrative for
| authentication/authorization/user management SaaS companies
| to build trust with their customers than to exploit that
| trust.
|
| Furthermore, with the economies of scale, there can be more
| investment done on security & protection of users by a common
| element. Think of it as a collection of companies pooling
| their resources on a single engineering team which is
| responsible for building a rock solid authentication system
| with many useful features. This helps little guys build on
| top of something which has the same efficacy as auth services
| that large companies can afford to build.
|
| At the end of the day, it's a trade off.
| bsid wrote:
| Hey, Braden one of the founders. It's a good question, and a
| question that gets asked a lot. Out of curiosity would you
| trust a more established company like Auth0 or Firebase? We
| hope to gain developers trust over time, and we want to build
| a tool that makes it dramatically easier to build out session
| management, and a lot of these user flows.
|
| A similar question that was asked only a few (10?) years ago,
| was "why would I trust a third party with my credit card
| data?" And now it's something that people don't think twice
| about, because of all the regulatory challenges around
| storing credit cards, and how bad a breach is.
|
| We see auth, and more generically, basic user data, as a
| corollary to that. With User Data regulations popping up in
| different countries (GDPR/CCPA), in the next 5-10yrs, we
| think it will become pretty common place to use a service to
| offload some of these gnarly responsibilities.
| rapnie wrote:
| > would you trust a more established company like Auth0 or
| Firebase?
|
| Auth0 maybe. Firebase is created by an advertising agency,
| so no.
| ziftface wrote:
| I can't speak for anyone else, but I would trust a service
| like this a lot more if i could easily export all my data.
| I would do so on a regular basis, basically as a backup.
|
| The other concern is what happens if you shut down or
| decide to change your plan to be prohibitively expensive?
| (I'm not implying that's the case for you, but it's a
| consideration that has to be made). There have been vendors
| in the past that have abruptly shut down without warning,
| leaving their customers scrambling to build or find
| alternatives. In all honesty, I'd rather build an
| authentication system from the beginning than having to
| take my service down at a critical time.
|
| This is actually a really interesting product though, and i
| would definitely consider it on future projects.
| taytus wrote:
| You didn't answer my question.
| tootie wrote:
| I can answer with the opposite question. Why would you trust
| your homemade solution instead of heavily invested experts?
| Auth0 (and Okta and a thousand others) do nothing but auth
| and customer management and do it at 1000X the scale as most
| enterprises. They do it way better than your IT team could
| possibly do it. And support every cutting edge feature and
| potential use case. You can also get them to absorb indemnity
| for damages in case of a breach rather than absorbing the
| cost yourself. From my POV, you'd be nuts to try to own your
| own passwords if you're securing anything remotely valuable.
| aidos wrote:
| Both of the services you mentioned have had major outages
| in the past. Maybe it'll never happen again, but your
| customers don't want to hear about why they can't currently
| do business because some service they don't even know
| about, in which you're hosting their data, isn't working.
|
| As ever, there are trade offs and you take the good with
| the bad.
| sixstringtheory wrote:
| Outages occur all the time. What difference does it make
| where exactly they're originating from if the end result
| is the same, from the end user's POV? You give them the
| same message in either case: "we're experiencing a
| temporary outage and are working on a remediation." I
| suppose you'll also be compensated according to contract
| SLAs, and if the hypothetical becomes actual, you can
| tune your contract renewal based on your observed losses
| in revenue accordingly.
|
| Best case scenario, there's healthy competition in the
| space, providing more alternatives and allowing you to
| end your contract with them if the service sucks. Worst
| case scenario I guess is that the company implodes taking
| all its data with it, affecting untold amounts of
| businesses. A GDPR-like regulation stipulating the
| ability to export that data (so, user databases) would go
| a long way towards mitigating prolonged outages in that
| worst case, and in the best case of the worst case, their
| competitors are able to import the exports. And/or tools
| that can spin up a $database instance in $cloud.
| dsr_ wrote:
| If UnicornAuthorization manages ten billion credentials,
| one breach could kill the company... and severely wound
| every single customer.
|
| If JaneService manages ten thousand credentials and has a
| breach, it could put JaneService out of business, but it
| won't affect MonicaSoft.
| new_guy wrote:
| Authentication is webdev 101. If you can't roll your own
| you're in the wrong industry.
|
| I really can't think of any good reason to hand crucial
| control of a site over to any third party, much less user
| authentication where one breach will potentially cost you
| millions and land you in jail.
|
| The whole business model seems to revolve around being a
| crutch for people not capable or competent of running their
| own services.
| tschellenbach wrote:
| Well, if you look at how many sites break auth, or
| something in the login flow... This is clearly not the
| case for most companies. Auth is definitely simpler than
| most problems, but plenty of teams get it wrong.
| tootie wrote:
| Building a form and hashing a password is webdev 101, but
| go look at the feature set offered by Auth0 or other CIAM
| platforms. Passwordless auth, MFA, compliance management,
| customer profiling, workflows, threat detection,
| analytics. And then think about how much they charge for
| doing this all for you out of the box versus hiring a dev
| team and running them forever to support it.
| chickenpotpie wrote:
| > I really can't think of any good reason to hand crucial
| control of a site over to any third party, much less user
| authentication where one breach will potentially cost you
| millions and land you in jail.
|
| Because Auth0 and other providers have security experts
| specializing in prevent hacking attempts and there is no
| way you can do a better job than them unless you make it
| your full time job.
| yannoninator wrote:
| or, you could just do passwordless email auth and not
| have any security issues whatsoever.
| mynameisvlad wrote:
| Sure, because "do passwordless emails" is just a snap of
| the finger away, right?
|
| The point is that doing auth _properly_ is hard. Sending
| an email might be easy, but creating and managing the
| session in a secure fashion is hard, even if you're "just
| doing passwordless email auth".
| chickenpotpie wrote:
| "Not have any security issues whatsoever" is literally
| impossible. Passwordless auth is the security equivalent
| of putting all your eggs in one basket. If someone hacks
| a users email account, now they have access to your
| service too. Now I'm pissed that you didn't let me enable
| 2fa to prevent that or have multiple secure passwords to
| isolate the hack to my email. You could have just shelled
| out the 10 cents it would have cost to have my account in
| auth0 and prevent all of this with 2fa and fraud
| detection.
| taytus wrote:
| Because I'm a software engineer who has been building stuff
| like this for years...
| ketzo wrote:
| I mean, if you're an auth expert, that's awesome; but I
| think it's the absolute height of engineer hubris to
| pretend that the efforts of _any_ one individual, no
| matter how talented and experienced, are able to match an
| entire organization of people who do _nothing_ but this
| one thing.
|
| Now, trusting _this particular_ third-party? Definitely a
| big question mark! It 's on them to earn your trust. But
| I think to say that _third parties in general_ can 't be
| trusted with your users is to be a little ignorant of the
| modern web engineering landscape. We trust a lot of
| people with a lot of things, and not in an unreasonable
| manner.
| sschueller wrote:
| Also, is this permitted under the GDPR?
| sofixa wrote:
| As long as clerk.dev are compliant, and you make sure of
| that, yep, you can delegate them data and keep yourself in
| compliance.
| renewiltord wrote:
| Yes, you (the "data controller") use them as a "data
| processor" and if they act compliant with the requirements of
| one, you're all well. Stuff like this is what the "data
| processor" definition is for.
| xyst wrote:
| It's shiny and new, but the privacy policy stinks. It reminds
| me of Google's shady practices.
|
| "8. Disclosure of Data
|
| We may disclose personal information that we collect, or you
| provide:
|
| ...
|
| Other cases. We may disclose your information also:
|
| to our subsidiaries and affiliates; to contractors, service
| providers, and other third parties we use to support our
| business; for any other purpose disclosed by us when you
| provide the information;"
|
| --https://clerk.dev/privacy
|
| Who are these "subsidiaries" or "affiliate" companies? Data
| brokers?
|
| From a company perspective it might be worth it to shave the
| 2-3 months to develop and perfect your own system. But from a
| user perspective, you are selling them out. Most people may not
| notice, but do you really want to risk the legal exposure or PR
| nightmare if their affiliate companies abuse this user data, or
| perhaps a subsidiary company leaves the data unencrypted in
| some db instance.
| yuppiepuppie wrote:
| As someone who uses Django which has user management out of the
| box, why would I use a service like this?
| dannycastonguay wrote:
| "Batteries included" Django is a no brainer for a lot of use
| cases. True. But clerk.dev seems to be targeting teams that use
| (javascript) microframeworks. They are building something
| people want and the pricing seems to scale well up to 100K
| users. If you have millions of users, I'm sure their enterprise
| team will give better deals than $0.05 / MAUs.
| [deleted]
| [deleted]
| TameAntelope wrote:
| Django does not have this feature-set out of the box, that's
| for sure.
| [deleted]
| theonething wrote:
| Laravel does if you count installing their starter kit as out
| of the box.
| glutamate wrote:
| I think Django has by far the best story here, so much built in
| or activated with simple plugins. It took us an hour to add
| 2FA.
|
| On the other hand, looking at node.js it's really a dumpster
| fire[1]. Even when using passport, you are still back to
| writing the code to compare passwords at which point so much
| can go wrong. So there's a lot of scope for hosted services.
| This of course compounds the problem because those service
| providers are GREAT at SEO and content marketing, so now a lot
| of Google hits on nodejs auth end up recommending Auth0
| &friends.
|
| [1] https://medium.com/hackernoon/your-node-js-authentication-
| tu...
| tschellenbach wrote:
| Common use case is when you multiple apps that all require the
| same auth infrastructure. IE a suite of apps for a business.
| spankalee wrote:
| Are the components only available for React?
| Rauchg wrote:
| Really good stuff. The Next.js integration story is already
| really quite good[1] and the Clerk team has really good ideas on
| how to make it even better and more seamless.
|
| It's great to see a service focus on taking away _all_ the pain
| related to user management, not just login.
|
| [1] https://frontend-docs.clerk.dev/react/quick-starts/next.js
| giacaglia wrote:
| It looks great!
| bsid wrote:
| Thanks Guillermo :) means a lot coming from you! We're really
| excited about the direction the development space is moving,
| next.js, react and frontend components are going to make full
| fledged web apps MUCH easier to make
| kleiba wrote:
| For potential users in Europe, is there any documentation on
| GDPR-related questions somewhere?
| kleiba wrote:
| Downvoted? Why? When user-related information is outsourced,
| the GDPR is absolutely relevant. Even the Google(!) screenshot
| on the landing page shows "Privacy and personalization" as the
| first item, that goes to show...
| bsid wrote:
| Braden, one of the founders, I gave you an upvote! GDPR is
| definitely at the top of our mind.
|
| We would love to make it so developers don't need to think
| about, or make it easy to think about, GDPR and CCPA, and any
| future regulations that come up.
| kleiba wrote:
| Thanks, Braden!
| emj wrote:
| The question becomes; where is your company incorporated,
| where are your servers located. I was looking around on
| your website and it's very light on such details.
| somid3 wrote:
| love it!
| colinclerk wrote:
| 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.
| kleiba wrote:
| @colinclerk, the "Explore documentation" link on the front page
| is dead.
| colinclerk wrote:
| Thank you! Resolved.
| laurent92 wrote:
| So is it the same as Login with Facebook or Google?
| Google/Facebook/Clerk manages the GDPR (do you? that is 300%
| added value for a business) and the app can focus on the data?
|
| Is your main added value that you are not Facebook/Google?
| dubcanada wrote:
| Just wonder price wise, if I signed up for the free and then
| switched over to paid it would be $249 for 5000 MAU.
|
| Compared to say Auth0, which would be $114 for 5000 MAU.
|
| The only difference is profile, and Auth0 mostly covers it by
| allowing you to easily store metadata.
|
| I am not sure I understand what makes Clark worth 2x Auth0?
| ukulele wrote:
| Just wait until you find Userfront, which does the same thing
| for free until 10k users
| dubcanada wrote:
| Another question, I don't see any mention of security. You are
| in complete control of our users/profiles and their login
| credentials and there is zero mention of how secure that data
| is.
| philip1209 wrote:
| Agreed - but I would also be interested in knowing if they
| hold cybersecurity breach insurance. That way, users could
| actually submit a claim for major issues.
| colinclerk wrote:
| 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.
| itisit wrote:
| SOC 2?
| colinclerk wrote:
| Not yet. We plan to pursue SOC 2 as we build out
| Organizations, since it's a clear requirement in a B2B
| context.
| bpicolo wrote:
| Glad you chose cookies for this versus localstorage JWT
| tokens. Kudos for that.
| f430 wrote:
| I forget what this effect is called. Every once in a while a
| new service comes along that tries to compete with Amazon and
| there is a huge cost of entrusting the new entrant.
| ketzo wrote:
| I think I've seen the term "trust moat" used before, which
| I like for describing this effect.
| f430 wrote:
| sort of like "economic moat"...yeah I can definitely see
| why AWS is quickly becoming a monopoly. 10 years ago? I
| might have used Clerk, I guess I'm not seeing what the
| value proposition here is to me its:
|
| Do I trust a new service or continue with one of the most
| trusted service from AWS?
| ketzo wrote:
| Yeah, definitely. It's a phenomenal virtuous cycle for
| AWS.
|
| I think that honestly, the biggest sell for a lot of
| newcomers is gonna be "you don't need to know AWS!" -- in
| my (very limited!) experience, if you want to do X with
| AWS, you're gonna need to learn how to do W, Y, Z, and
| maybe A and B with AWS too.
| gravypod wrote:
| Seems like an amazing product! One thing that would be amazing
| for you to tackle is support for devices, services, etc. Things
| that are not driven by a user and do not have a browser. I've
| worked at a few IoT companies and authentication is always a
| massive pain in my ass. SSO for web pages is annoying,
| authentication for 3rd party APIs or devices that need to sit
| in the middle of nowhere and don't have people to "login" on
| them is a whole other layer of pain. I'd love if you had a
| solution in that area.
| colinmorelli wrote:
| What's the story around extensibility? I feel like it starts to
| get murky when the boundaries of data ownership are unclear. What
| if I have some bespoke user-level data that doesn't make sense
| for your system to store, but is massively important to my
| business (this feels to be the case for most products I build).
|
| Can customers extend your UI components? Do they store that data
| with you? One of the nice parts about authentication only is that
| it's relatively well-defined and not a place where customers
| frequently have variable needs (outside of just data sources to
| auth against).
|
| Cool idea either way though, and I like seeing more innovation in
| the space.
| colinclerk wrote:
| 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.
| colinmorelli wrote:
| Thanks for the reply! I think your last point is what worries
| me the most. I feel like it makes sense to tackle custom
| attributes, because you own the user management pages. But, I
| also feel like you're almost never going to be able to
| support the kind of flexibility customers will need if those
| fields are anything more than simply metadata.
|
| It's nothing about Clerk specifically, it's just a problem
| with these kinds of products. I just worry that as your
| customers grow and scale, they naturally need to leave your
| platform (or downgrade to an auth-only solution). I'll
| definitely be curious to see how the product grows, though!
| colinclerk wrote:
| 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.
| asimjalis wrote:
| Nice. If you could also add the ability to charge subscriptions
| from users and manage their subscription plans this would become
| a no-brainer. Also your pricing model could become very lucrative
| --you could charge a percentage of the revenue.
| colinclerk wrote:
| 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?
| asimjalis wrote:
| In my case I don't care about organizations. I am an
| individual dev who would love to use something like this to
| easily build apps that I could monetize. I am thinking of a
| web equivalent of the Apple iOS app store. Some place where
| you write an app and let the app store take care of billing
| and payments. I have published several iOS apps and zero web
| apps mostly because there is no frictionless way of
| monetizing web apps. Feel free to send me email if you want
| to talk more about the use cases.
| ketzo wrote:
| Both of these are definitely features I would _really_ dig,
| particularly if I 'm able to subscribe to whichever one I
| need.
|
| If I'm building a photo-hosting app, it would be a bummer to
| pay for/build out a big "Organization Subscriptions" feature;
| if I'm building an enterprise-oriented chat application, I
| wouldn't want to spend many hours or dollars on individual
| "User Subscriptions".
|
| But that said, I recognize splitting out those two features
| is more of a cherry on top; the main value here is just
| having them available to me in the first place. Either way,
| definitely keeping my eye on Clerk! Good luck folks!
| tootie wrote:
| This is cool and all, but it's definitely not a new vertical.
| There are dozens of CIAM vendors up and down the value chain who
| do more than authentication.
| [deleted]
| nautilus12 wrote:
| I'm waiting for SaaSaaS. SaaS as a service.
| purplerabbit wrote:
| I would unironically buy this... probably 20% of my job is
| wrangling SaaS boilerplate.
|
| Am I alone on this? Let's be honest, how much of the SaaS code
| you write could be applicable in _any_ SaaS application?
| grinich wrote:
| What's your job?
| zorbash wrote:
| Is the User schema[1] extensible? Can I add custom attributes or
| metadata to my users?
|
| [1] https://frontend-docs.clerk.dev/object-reference/user
| bsid wrote:
| Hey, Braden, one of the founders, very soon. This one is
| definitely low hanging fruit, and I actually want it as well
| for a side project I'm helping a friend with :)
| RyanGoosling wrote:
| I like to use .NET Core Identity services with Azure AD B2C. Very
| easy to setup and generic interfaces are already defined for
| password reset, etc.
|
| https://docs.microsoft.com/en-us/aspnet/core/security/authen...
| _rohan wrote:
| This is great. Do you have plans to provide any native mobile
| (iOS/android) support?
| catchmeifyoucan wrote:
| This is very promising! Going down this path now.
|
| 2 questions:
|
| 1. What happens if you go down? Then our users can't auth in
| right?
|
| 2. I saw in one of the screenshots the ability to connect OAuth
| providers - will your service also store refresh tokens for these
| api services?
| mritchie712 wrote:
| Do you handle teams? Eg for a b2b SaaS?
| bsid wrote:
| Hey there, this is Braden, one of the founders - not yet.
| However, we're actively working on this :) We're probably going
| to start with basic RBAC/invitations before getting into
| planning for the full feature set -- which will include
| SSO/SAML/ more complex permissions (possibly ABAC), Audit Logs.
|
| Since we're tackling both the APIs and the customer-facing UIs,
| we think we'll be able to add a lot of value here
| blhack wrote:
| Okay now add billing to this and rocket to a $1B+ valuation.
| polote wrote:
| Few things I dont get:
|
| - Who is your customer type ? Individual developers ? IT of
| companies ?
|
| - What do you bring in addition to Google G Suite ?
|
| - Why is that important to have beautiful UI ?
|
| - Why would I use your service to power auth of my service, as it
| would probably take more time to integrate your apis, and
| configure your frontend to my branding than do it from scratch ?
| colinmorelli wrote:
| Not OP, but:
|
| - Presumably, engineers building customer-facing applications
|
| - Google G Suite can be a fine SSO solution for internal apps,
| but isn't the thing you're going to use for your customers
|
| - I'm not sure how to answer this one. Surely it's quite
| obvious how a beautiful user experience is valuable? Your
| customers aren't comparing your experience against your
| competitors, they're comparing you to the best experience they
| have seen to date in any space. Companies who don't invest in
| their experience (and by extension, their visual design) will
| fall behind.
|
| - At a surface level this may appear true, but in practice
| people often significantly underestimate the time involved in
| building a high quality and secure authentication system. If
| all you do is throw an email address and password in a table,
| then sure. But you're going to have sign up, log in, forgot
| password workflows (and emails) at the very least. Then, if
| you're actually trying to protect something, you're going to
| have password complexity requirements, brute force protection,
| 2FA (authenticator, sms, etc), security notifications, browser
| fingerprinting, etc - to name a few.
|
| I'm still not sure how I feel on the outsourced authentication
| concept, but certainly not because building your own auth is
| free or cheap. Just because it's such a critical part of data
| that it might be worth eating the cost for (but I'm not sold
| necessarily).
| jzer0cool wrote:
| Is this hosted on your own backend? Should the time or need arise
| if available, what are some recommended steps to migrate off if
| needed?
| xwdv wrote:
| What startup is moving so fast they don't even have time to write
| their own user management features and instead outsource it to a
| third party SaaS in perpetuity?
| bluefirebrand wrote:
| Basically all of them these days.
|
| Somewhere someone convinced us all that
| "Authentication/Authorization" are hard problems that we should
| leave to third parties.
| sixhobbits wrote:
| Definitely see the need for this but its not that clear to me how
| it differs from eg FusionAuth which is positioned as an "Auth"
| solution but actually does everything(?) you call "user
| management"
|
| Not necessarily criticism, just my impression after a quick
| glance.
| ucarion wrote:
| Two questions:
|
| 1. Why use this over AWS Cognito?
|
| 2. Any intention to manage authorization as well?
| SahAssar wrote:
| I'm probably not the main audience for this, but if you mention
| security as a top-level feature it might be good to fix these:
|
| https://securityheaders.com/?q=https%3A%2F%2Fclerk.dev
| https://securityheaders.com/?q=https%3A%2F%2Fdashboard.clerk...
|
| For me it is also a red flag to include third party CDN JS
| (especially without SRI) on security critical applications (like
| the login for the dashboard and customer logins do with
| jsdelivr).
| QUFB wrote:
| It's not an especially good look, although I see in the past
| few minutes HSTS has been enabled!
| SahAssar wrote:
| It's the same as before, clerk.dev does not have it and
| dashboard.clerk.dev had HSTS when I checked first too. HSTS
| is sorta irrelevant for .dev though since all of .dev is on
| the preload list in major browsers. I'd be more worried about
| the third party JS without SRI.
___________________________________________________________________
(page generated 2021-02-08 23:00 UTC)