251–259 of 259 posts
Earlier quoted context omitted.
Django, Rails etc handles this.
So... you just have to not build your web app in the most popular web app language? Somehow i think there will be big time debt from that decision
Earlier quoted context omitted.
Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…
This is such an absurd take. For starters, if I'm a "house builder" by trade, then yeah, I am going to build the house myself. Otherwise, why should the client pay me, and not the guy I'm subcontracting? Secondly, there is no such thing as a "house builder" profession. It consists of a lot of different trades people, some of them having legal power to sign off your house build (for example an electrician). Now, we co…
It’s humorous that these conclusions are that the only option is SaaS or write it yourself, while my comments were about not doing things yourself, not that a SaaS is the only answer. Interesting that is how you felt the need to take it.
People are rarely as clever as they think they are at preventing others from doing something, while others only need to find one thing wrong. “Write it myself” is about the dumbest answer to that problem if you do not have the same level of resources to commit to that specific problem as can be solved by someone else.
Not really a hot take to state something so…basic..but you’re welcome to conclude what you like.
Earlier quoted context omitted.
Your comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password. > There must be a behavioral pattern there... The pattern is that your comment is very far from reality.
My point is that people mess up things as basic as salt and pepper, or encryption at rest. People are not even trying... If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex. I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.
Earlier quoted context omitted.
BetterAuth is users in your own database. So you don’t have to!
Why better auth and not, postgres in docker? What is it better about better auth compared to the ol reliable postgres?
Earlier quoted context omitted.
> Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. I agree with the general principle. Fewer moving pieces make for more stable applications ("choose boring technology"[0]). However, I was wondering what you do when you have more than one application that the same userbase wants to access. I can see 3 options: 1. make them regist…
I think depending on how much integration you want, either option 1 or treating the multiple applications as a single application that can do multiple things could be good options. Also, option 2 could still avoid having to worry about your auth service going down or rate limiting you. And you could avoid JWT headaches. Perhaps there is also an option 4, which is option 1 plus a shared user information database for t…
1. store everything user related in there, rely on APIs or syncing if the application needs user attributes
2. store nearly nothing in there, just credentials, MFA, account recovery info and anything else related to authentication. All profile data is stored in each app
Both can work, they just have tradeoffs.
Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects. - Syncing external auth provider state with your user state is a bug center. It helps to keep as little state a…
We're working on multi-app support. The large majority of our customers only have 1 app (ChatGPT, Claude, Cursor, etc.) but this isn't the case for developers building lots of side projects.
Also working on shipping an agent-friendly Dashboard. Stay tuned :)
Would love to hear any more feedback: mg@workos.com
Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail. Would think twice before using it in the future.
i'm currently in the process of evaluating switching our b2b app off clerk too. a customer asked for custom roles (diverging from our default set), which is technically possible on clerk now with role sets, but it's a bit of a workaround rather than first class. thankfully i'm familiar with better auth from a side project, but migrating SSO/SCIM sounds like it might be a bit of a pain
I think we have the most advanced RBAC system. You can even map roles from custom IdP groups via SCIM.
More info here: https://workos.com/guides/user-provisioning-scim
Earlier quoted context omitted.
My point is that people mess up things as basic as salt and pepper, or encryption at rest. People are not even trying... If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex. I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.
No. OIDC and in general identity management + entitlements in a large business organization is complex because we need that complexity.
Having had the chance to try and implement libraries to interface with those systems a couple times, most people agree that implementations are far from perfect or streamlined. We call this incidental/accidental complexity.