This is a terrible suggestion. Rolling your own auth nowadays is like rolling your own encryption. It’s just a bad idea. OAuth and OIDC are massive specs that are constantly changing and you’re going to be stuck chasing and developing auth instead of your actual product.
I know because this is what my brain dead principal engineer did and I’ve spent the last 3 years chasing RFCs and am now going to spend the next year migrating to Keycloak because I’ve finally convinced my boss that we’re not an auth company.
I agree you shouldn't write every line by hand, you should use libraries, but pretending like OAuth/ODIC require using something like Cognito/Auto0 is just silly. An LLM can crank out the needed code in very little time and give you full control over your auth instead of fighting an auth provider at every turn.
The number of compromises something like Cognito requires are just not worth the perceived gains.
I really whole heartedly disagree and if you think it’s silly I think that you don’t really fully understand the complexity of it. An LLM doesn’t solve everything. You still need to understand the spec, become a domain expert, and design your solution for the parts that the RFCs leave open with undefined behaviour. At the very least if this is your opinion you should start with an open source solution like Keycloak or authentic and fork it if you really need “control”.
I already said that using a library (open source) is a good idea, I just don't think we need to pretend that Auth is so complicated that we need a third-party provider. I don't buy that argument. You should not roll your own low-level code, you should never need to even look at the RFC's, just hook into the Auth library you use (library, not service).
> just hook into the Auth library you use (library, not service).
I think this is a fundamental misunderstanding of how this stuff works. You can't "just use a library". Your identity server is a service, open source or not and you have to align to how they do things.
I'm talking about handling the OAuth token exchange and what not. Your identity server doesn't need to be a separate service, it can be integrated into your backend. At the end of the day it's responsible for making sure client claiming to be X is X. I really don't think this is rocket science.
I've set up email/password, email magic links, SMS 2FA codes, OAuth, and it's never been this magical, mystical thing these "auth providers" want to pretend it is.
Yes, you need to wire up endpoint for you to feed data to the library (tokens), and provide ways to refresh tokens, etc but that's all just wiring up and I don't think that's really that hard (even before LLMs).
I just cannot fathom handing over as much control and third-party auth providers require you to.
It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard.
The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.
> Go works better than other languages for those who have what you call "a talent issue"
This is actually true and by design; a bit more nuanced from [0]: "Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."
Talent is important, but doesn't scale. You can have the best of the best software developers but it's a moot point how talented they are at industrial scales (hundreds of applications, tens of millions of LOC, thousands of developers, tens of thousands of features, decades of work, etc)
Note that "early in their careers" from the perspective of the author is basically <20 years of experience.
I do. Bike sheds do need to be painted after all, but its many less people who have the technical experience to know how many feet away from the property line it must be.
When I joined my first startup, they said if you didn't have a good plan for going public or getting acquired by series C, then the D in series D stood for death. Uber et al raised like a J round. None of the rules around markets or investments are real, it's all vibes-based, and the decision-makers love talking to their ChatGPT mistresses too much to let this all come crashing down.
Yeah. Uber's a successful company and they raised a J round. Therefore the rule (D means Death) is not real. I'm not sure what you're implying, or if you just misunderstood the original comment?
>or if you just misunderstood the original comment?
Did you? If you keep on reading, the parent comment further implies that both AI companies and uber are "vibes based". But that's hard to square with the fact that 7 years since IPO the share price is up 75%. Of course, you can argue we're still in the irrational exuberance stage, but that just creates a situation where you can never be called wrong.
> But that's hard to square with the fact that 7 years since IPO the share price is up 75%
Uber has severely underperformed the market. Passive S&P500 index funds had a total return of more than double that in the same time period, while also having less risk than investing in a single stock.
Obviously much worse outcomes are possible than Uber's, but it's far from a massive success, especially after all that hype! This isn't to say the old common wisdom about excessive funding rounds was valid, but it's not completely invalid either.
I don't think so. They say the rules are vibes-based (or just wrong). That means you cannot use the rule to draw conclusions. That does not mean "the opposite of the rule is true" or anything like that. Nor does it mean that the AI companies resemble Uber in any significant way. They are just saying that since the rules are not real, you cannot say something like "this business will obviously fail, because it has bad fundamentals". The fundamentals are only part of the equation.
reply