Mike Schwartz
I also agree that giving developers easy to use libraries (you don’t write your own database or messaging library, why would you write your own OAuth library?), and middleware services that do some of the heavy lifting is a good thing. Gluu has spent years developing the OXD middleware service to do some things in the background, like validating signtures, using private key authentication at the token endpoint, and following other good practices. Auth0 has also done a good job in this regard.
And you are certainly right that developers don’t generally care about all the risks that are mitigated by properly implementing an OAuth / OpenID Connect client. However… the organization that is protecting a user’s credentials, their personal information, and their resources… they MUST care.
If you are a developer, and your code is responsible for leaking personal information… it has a financial impact on the organization for which you’re working. And it also has an impact on the person whose information is leaked. So to be a responsible developer, while it may be desirable to wash your hands of the whole thing, you need to practice a minimal level of security hygiene. Even if you use helper middleware services, excellent client software, or web filters (like mod_auth_openidc), you need to understand some of the basic security issues around federated identity. Knowing nothing is the equivalent of developer malpractice.
Anything unfamiliar is complex. OAuth is not inherently more complex then many of the things developers do. The technology in my phone is magic. Redirecting a user to a web page with a few parameters is significantly less mysterious.
One of the reasons I published my book Securing the Permeter, was to explain the concepts in simpler terms.
But what is both unproductive and detrimental to the industry is disparaging the good work that has been done.
Yes, please keep innovating. Come up with a better solution. I’d love to see an idenitty layer that does not rely on the web browser redirect. Someone, please invent that!!! But until that time, we need to support the best solutions we have today.
The question is what is the minimum amount of information that a developer needs to know? And that depends on a few things. How much personal information may be exposed in a breach, and how sensitive is that information? What is the transaction value of the resource being protected? How likely is an attack? What is the tangential impact of an attack? Based on the answer to these questions, developers can figure out how deep they need to go into the weeds.
@markstos : OpenID Connect is basically OAuth SAML. Completed in 2006, SAML did not think about things like SPA’s or mobile phones (iPhone came out in 2007…). SAML defines an identity assertion–it’s a signed XML document that tells you things like who the person is and how they were authenticated. OpenID Connect also defines an identity assertion, called the id_token. Instead of signed XML document, it’s a signed JSON document. But it contains basically the same information. I would think that consuming JSON documents is not too complicated for developers. And validating signatures does not seem inordinately complex either. It’s easier then XML canonicalization, which has been fraught with parser library risk.