Re:What Is OIDC?
by bob1029 on Friday December 22, 2023 @06:46AM
(#38733265)
Our current production deploys for our B2B/SaaS banking product run "in-house" authentication.
We were essentially laughed out of the room when we showed our biggest prospect how we managed users in our legacy product. I felt really smug about my fancy hand-coded user management tooling until about 50% into the presentation when I could see an equivalently-smug look + mild sideways head shaking coming from the customer CTO. Running in-house authentication is literally a joke to many of these orgs in 2023. Most developers probably won't ever experience this. I think it is a shame, because this one experience forced us to embrace a new kind of light that much of HN probably won't ever see. Our roadmap was accelerated by this rejection.
Realizing that we might have lost a multi-million dollar customer over an ego trip was a bit of a wakeup call. I have some skin in this game. I don't know about the rest of HN. At a certain point, it's about making money and being able to sleep at night. Running in-house anything typically works against that (i.e. spending finite innovation tokens). Like it or not, if you are dealing with a big crusty organization, outsourcing authentication might become mandatory at a certain point.
Further, if something goes wrong and one of our customers gets breached, I don't want the investigation to wind up at a line of code in my codebase. That means I have to get involved in legal proceedings. I am completely out of the game of touching end-user passwords or MFA tokens now. We get claims from an IdP and that's that. We don't even write SAML/OIDC integration code because our tech partner has done that for us by way of a happy DDL election on our FaaS runner config. The authenticated user's claims are injected into our HTTP trigger function arg list, and since we do stupid-simple PHP-style SSR web apps, the rest is fairly obvious. We still have a "Users" table, but all that password hashing/salting/iterations crap is replaced by a simple UPN string field (i.e. the user's email address).
Above all this, use case matters most. If you are unregulated and dealing B2C with 100m customers, you'd have to be the maddest hatter to ever live to consider paying someone else for authentication duty like we decided to do. If you are working B2B with US banks and other regulated orgs, the exact opposite appears to be true.
We were essentially laughed out of the room when we showed our biggest prospect how we managed users in our legacy product. I felt really smug about my fancy hand-coded user management tooling until about 50% into the presentation when I could see an equivalently-smug look + mild sideways head shaking coming from the customer CTO. Running in-house authentication is literally a joke to many of these orgs in 2023. Most developers probably won't ever experience this. I think it is a shame, because this one experience forced us to embrace a new kind of light that much of HN probably won't ever see. Our roadmap was accelerated by this rejection.
Realizing that we might have lost a multi-million dollar customer over an ego trip was a bit of a wakeup call. I have some skin in this game. I don't know about the rest of HN. At a certain point, it's about making money and being able to sleep at night. Running in-house anything typically works against that (i.e. spending finite innovation tokens). Like it or not, if you are dealing with a big crusty organization, outsourcing authentication might become mandatory at a certain point.
Further, if something goes wrong and one of our customers gets breached, I don't want the investigation to wind up at a line of code in my codebase. That means I have to get involved in legal proceedings. I am completely out of the game of touching end-user passwords or MFA tokens now. We get claims from an IdP and that's that. We don't even write SAML/OIDC integration code because our tech partner has done that for us by way of a happy DDL election on our FaaS runner config. The authenticated user's claims are injected into our HTTP trigger function arg list, and since we do stupid-simple PHP-style SSR web apps, the rest is fairly obvious. We still have a "Users" table, but all that password hashing/salting/iterations crap is replaced by a simple UPN string field (i.e. the user's email address).
Above all this, use case matters most. If you are unregulated and dealing B2C with 100m customers, you'd have to be the maddest hatter to ever live to consider paying someone else for authentication duty like we decided to do. If you are working B2B with US banks and other regulated orgs, the exact opposite appears to be true.