1. 5
  1. 13

    Low value marketing piece.

    1. 4

      I got this comment on HN too, but not sure why…

      I tried to write something that is relevant to what I work on every day, and is really frustrating in the security industry. Not trying to market anything to anyone with this piece – we (Okta) aren’t that good at this either.

      1. 10

        I think if it wasn’t on the corporate blog it wouldn’t be read as a marketing piece.

        Also, you spend the article picking apart the problems with OAuth and OIDC, and then go on to mention your product is built on them:

        This is one of the reasons why, here at Okta, even though our entire platform is built on top of OAuth and OIDC, we spend tons of time and effort trying to build abstractions (in the form of client libraries) to hide those complexities and make securing your web applications simpler.

        I’m sure you meant well, but unfortunately corporate engineering blogs talking about anything remotely near what they do for revenue is a damaged brand. Waaay too much spam has been generated that way.

        1. 9

          The premise of the piece is just the old marketing saw that nobody wants a drill, what they want is a hole in the wall. Or better yet, to have that family portrait hung. I mean, yes, that’s true, but it’s not a very interesting insight at this point.

          I’ve just gotten done with exactly the problem you describe: the specs require specialized knowledge to read, the protocols can be confusing, and we don’t really need all the flexibility OIDC offers. I should be your perfect target market.

          But the “nobody cares” title and premise led me to think you were leading up to a great unveiling of a superior solution. Some newer, shinier, or easier spec to deal with. Reaching the bottom of the post to see that you offer a wrapper library to make it easier to talk to your implementation of the specs you just got done telling me not to care about… well, it felt a bit like poor old Ralphie decoding his “Drink your ovaltine” secret message.

        2. [Comment removed by author]

          1. -3

            but also +1

        3. 2

          It will be a good one if it’s not just promoting Okta at the end.

          1. 2

            I just finished rewriting a Node service to use OAuth & OIDC directly without any frameworks after I realized how simple it actually is and how much the framework layer just served to obfuscate and confuse. It was also using session cookies in a way that was completely unnecessary in our case and which also resulted in some intermittent problems for users.

            1. 1

              The article was good, can’t say I’m a fan of the clickbait-y headline though

              1. 1

                “99.99% of developers out there don’t know (or want to know) anything about OAuth, OIDC, or any other security specifications. “ Where did this come from?

                Don’t get me wrong, if the gist is “developers are fatigued from having to deal with authentication between services, and it’s easy to get wrong” then that is definitely true! But while this post has a uncontroversial conclusion, I’m not seeing any real solution offered to the issue.

                Of course using a 3rd party service might be a good idea in some situations, like using a hosted database would alleviate some of the frustrations of having to admin a storage layer. But in the end you still need to deal with some complexity, and it’s better to properly understand what you’re outsourcing, which means you still need to know quite a lot about it.

                Also 3rd parties might lock you in - so interface abstractions really do matter. To use the same storage layer example, if you were switch your db host, or decide to self-host, the db interface remains the same. But if instead of, say OAuth, you integrate with an abstraction on top of the OAuth standard, you then need to change everything that used to talk to that interface, should you decide to move away. This is not to fully reject this as a solution, but a consideration.