Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Three things to never build yourself: auth, notifications, payments

courier.com

Post reply on HN
Print view View original

181–190 of 193 posts

Re: Three things to never build yourself: auth, notifications, payments

#181

Post by RamblingCTO »

znpy wrote: post #157
rvense wrote: post #77

Earlier quoted context omitted.

I'm currently implementing Keycloak for my startup. It's not perfectly documented, but I really like all the things it can do for us and how extensible it is.

> It's not perfectly documented I want to chime in to this too. If anyone from the Keycloak project is reading: keycloak is awesome, but the documentation is really the most painful part. The main problem is that it assumes that people installing and/or configuring keycloak already are JBoss/J2EE experts. Please assume knowledge of GNU/Linux systems, the OAuth/OIDC stuff, LDAP and SAML, but do not assume knowledge of…

They know about that quite well actually. But there's also Keycloak X in the works which is based on Quarkus. It's not mature enough yet but I hope they tackle a lot of the bad things.

Re: Three things to never build yourself: auth, notifications, payments

#182

Post by mooreds »

beachy wrote: post #162
mooreds wrote: post #134

Earlier quoted context omitted.

Awesome, appreciate the perspective. A few qs for you: My understanding is that you ended up writing java code to extend keycloak. Is that wrong? Is keycloak resource hungry or have I heard wrong? Have you tried keycloak X? Is that better? Is there a way to configure a dev environment? Is Terraform the preferred IaC solution? How many realms do you use typically?

> My understanding is that you ended up writing java code to extend keycloak. Is that wrong? Depends what you mean by "extend". For many operations, there are REST APIs, e.g. to create a realm (somewhat equivalent to a tenant in the SaaS world - though see below), it's simply POST /auth/admin/realms. There are also more elaborate extensions such as login listeners that if I remember correctly, you would build in Java…

Thanks for sharing your experience.

Always good to hear from someone who's actually used software rather than second or third hand perspectives.

Re: Three things to never build yourself: auth, notifications, payments

#183

Post by mooreds »

ozymandias12 wrote: post #128
beachy wrote: post #120

Earlier quoted context omitted.

I've never checked out your product, but we use Keycloak extensively and I can say it is a great Auth solution and I've used several and even built some (poorly). The only real downside of Keycloak IMO is the documentation. Because it covers so many bases, and is very extensible, the official doc is enormous. There are a lot of lightweight articles about how to use it, I'd use one of those to get started. Some great…

What other FOSS like Keycloak we have available in 2021? Looking to update my knowledge on options

Ones that I've heard of in conversation with customers:

   * IdentityServer (.NET)
   * The ORY suite (hydra, etc)
   * Gluu
I'd say Keycloak is the most common one I hear.

There are about 15 FOSS packages listed here, but you'll need to weed through what is an auth server and what is not: https://en.wikipedia.org/wiki/List_of_single_sign-on_impleme...

Re: Three things to never build yourself: auth, notifications, payments

#184

Post by DougN7 »

yoyonamite wrote: post #172
deckard1 wrote: post #158

Earlier quoted context omitted.

What's been interesting to me is that during tech interviews, we eagerly have applicants roll their own sorting, or searching, or caching. But you never have questions about crypto or auth. Why one and not the other? Are both not critical to get right? And then I'm reminded of the bug that was hidden in plain sight for 20 years in Programming Pearls [1] in their implementation of a binary search. This same algorithm…

Isn't signing the session cookie to prevent cookie tampering? You can send a random string, but you would need to persist the random string somewhere in order to verify against it later

The cookie value has to be stored in some sort of map\dictionary that links to the session data. If the cookie value is a random string, you don’t need to store any more data than you would with a hashed cookie value. Or maybe I’m misunderstanding your point?

Re: Three things to never build yourself: auth, notifications, payments

#185

Post by scsilver »

Not to be jumping on bandwagons but it seems to me like decentralized block chain based accounts abstract both payments and auth out of your app and into a unified audited protocol. And since its a ledger, couldn't you include notification information aswell? I feel like this is the killer feature of all these dapps, 2 of these features come built in.

Re: Three things to never build yourself: auth, notifications, payments

#186

Post by joshmanders »

beardbandit wrote: post #119
deergomoo wrote: post #107

Earlier quoted context omitted.

Not to mention there’s a whole lot of middle ground between writing your own auth logic and using a hosted service. Any reasonably popular web-oriented language has plenty of fully featured, high quality libraries you can often just drop in. Hell, we use Laravel at work, which includes pretty robust auth features out of the box. It feels like such table stakes stuff for a web framework that I find the idea of paying…

I think that's where the confusion lies. Are people suggesting someone to write their own auth from the ground up, or write auth in coordination with their stack's auth library of choice?

It appears to me the assumption these people / articles make is that nobody is using existing hardened production ready libraries, but hand writing everything from the ground up for their todo app.

Because otherwise their message falls flat on its face.

Re: Three things to never build yourself: auth, notifications, payments

#187

Post by joshmanders »

worldsoup wrote: post #21
blacktriangle wrote: post #7

Earlier quoted context omitted.

Exactly, how are all the Auth0 customers feeling about that acquisition?

unclear if we will all have to switch off Auth0 with the acquisition but I've built a company with Auth0 as the auth provider and definitely would not take it back, saved us so much time and allowed us to focus more time on product market fit

On the flip side the absolute mess of a headache my day job had during their recent what 3+ hour downtime, stopping our paying customers from accessing our perfectly working application that they pay for, because early days devs decided to use Auth0 instead of a battle tested rails auth lib has made us prioritize refactoring auth0 out of our system.

Re: Three things to never build yourself: auth, notifications, payments

#188

Post by AlchemistCamp »

ocdtrekkie wrote: post #35
rgbrenner wrote: post #27

Never outsource Auth. Maintain control over user accounts. That's the life blood of your business. If you have to ask everyone to reset their password because your auth provider increases their pricing or goes out of business, the churn will likely kill your company. I would say the same for Stripe, but at least they'll help you migrate off their platform. Auth providers cant help you because the passwords are hashed…

It is probably true that outsourcing your authentication to another party is probably bad, you probably should not write your own. So you should likely use a package for your auth code written by someone who focuses heavily on that.

In Elixir-land we're lucky. Jose Valim took his experience from writing Devise (the dominant Ruby gem for auth) and made auth generators for Phoenix apps!

You own the user table, but the auth logic is written by an expert.

Re: Three things to never build yourself: auth, notifications, payments

#189

Post by sjaak »

jaywalk wrote: post #40
sjaak wrote: post #15

Earlier quoted context omitted.

To make things easy I usually use "alg":"none". It makes using jwts a breeze. https://datatracker.ietf.org/doc/html/rfc7518#section-3.6

I hope this is a joke.

It was, but judging by the downvotes my delivery was off :)

Re: Three things to never build yourself: auth, notifications, payments

#190

Post by oblio »

scsilver wrote: post #185

Not to be jumping on bandwagons but it seems to me like decentralized block chain based accounts abstract both payments and auth out of your app and into a unified audited protocol. And since its a ledger, couldn't you include notification information aswell? I feel like this is the killer feature of all these dapps, 2 of these features come built in.

Do you have any examples of blockchain based account management?
Post reply on HN