3 ms·

It's not just an open source problem. It's fairly trivial to scrape the keys out of a lot of closed source applications. When Twitter first mandated OAuth, I wa

It's not just an open source problem. It's fairly trivial to scrape the keys out of a lot of closed source applications. When Twitter first mandated OAuth, I was able to grep a key right out of the apk of their native Android client. OAuth with client secrets is fundamentally unsuitable for desktop and mobile applications, but that hasn't stopped virtually every major implementor from using it that way. The people who wrote the spec were too busy congratulating each other and downplaying concerns to seriously engage with this issue until it was much too late to do anything about it. It remains a deeply broken standard, and the people who were responsible for it at an early stage are entirely to blame. Several of them have removed their names from the spec, but I'll not forget the role they played in shouting down critics who raised concerns about this very issue.

niftich 6y ago
Much of the deployment of OAuth2 was a shitshow, because early on, there was a huge debate about OAuth1 vs OAuth2, and the concepts and terminology used in the OAuth2 spec exceeded the mental load of people who were simply looking for a quickstart to some API. Docs by various providers either adopted the OAuth2 terminology wholesale without sufficiently explaining the new concepts and the best practices, or they simplified the client registration to just a few fields and offered no guidance as to make use of them in your app. The spec has been clear from the start that there are clients that can protect their secrets, and ones that can't [1]. Here's a choice quote: "A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted." Unfortunately, much of the rest of the spec is a bit like a playing puzzle, where reading it in one sitting doesn't actually build your understanding, and you have to constantly cross-reference various sections to construct a complete picture of the process the spec is trying to set. It look a long time for people's familiarity with the spec to grow, and for providers and clients to improve in quality and adherence to the ideas and text of the spec. [1] https://tools.ietf.org/html/rfc6749#section-2.1 https://tools.ietf.org/html/rfc6749#section-2.1

niftich 6y ago

Much of the deployment of OAuth2 was a shitshow, because early on, there was a huge debate about OAuth1 vs OAuth2, and the concepts and terminology used in the OAuth2 spec exceeded the mental load of people who were simply looking for a quickstart to some API. Docs by various providers either adopted the OAuth2 terminology wholesale without sufficiently explaining the new concepts and the best practices, or they simplified the client registration to just a few fields and offered no guidance as to make use of them in your app. The spec has been clear from the start that there are clients that can protect their secrets, and ones that can't [1]. Here's a choice quote: "A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted." Unfortunately, much of the rest of the spec is a bit like a playing puzzle, where reading it in one sitting doesn't actually build your understanding, and you have to constantly cross-reference various sections to construct a complete picture of the process the spec is trying to set. It look a long time for people's familiarity with the spec to grow, and for providers and clients to improve in quality and adherence to the ideas and text of the spec. [1] https://tools.ietf.org/html/rfc6749#section-2.1 https://tools.ietf.org/html/rfc6749#section-2.1