It explains why OAuth2 is hard to use and does not solve login, registration, sessions, profile management, mfa, and proposes another solution. It’s all open source! :)
The first vulnerability is in the title, OAuth is an Authorization framework (Open Authorization) and is explicitly NOT for authentication. It’s also a delegation protocol (I give you something to do on my behalf).
Ory | Open Source Software Engineer (Go, React) | FULLTIME | ONSITE in Munich Germany
We build stuff for an emerging cloud infrastructure. It's security, zero trust, hardcore bullet proof engineering. It's Golang, K8S, React, Hashicorp etc. - no more buzzwords!
We are looking for people with a broad set of technical skills who are ready to take on some of technology's challenges and work with others to create modern world class solutions. We like React, Go and Kubernetes (among other things) and love learning how to push the boundaries with those technologies!
Drop us a short introductory email to [email protected]. We believe that great engineering deserves to be paid accordingly.
The problem is that online news sources are (almost) all the same - low budget, second tier silos of mostly trainee journalists. They have an emphasis on clicks and outrage and constant updates to keep you engaged and are a secondary (or tertiary) driver of revenue. The only exception I know of are The New York Times and maybe The Intercept.
My tip is to read a (or more) actual (read: printed) newspapers:
- they are printed daily or weekly (e.g. The Economist), keeping you out of the "Breaking News" loop every 60 minutes;
- they have more weight within the news organization because they are the primary driver of revenue;
- are therefore written by actual professional journalists in a proper journalistic process.
I recommend just picking up any news paper and comparing that to the online presence of that news paper, you will notice the tremendous difference.
In my opinion, a lot of the "media mistrust" comes from the constant barrage of so-called "news" articles with the primary goal of being shared on social media and bubbling up in Google News. Just check how many news articles are 1:1 copies of AP or any other news conglomerate.
Username + Password with a cookie store is much better understood and harder to get wrong than implementing a full OIDC suite (server + client). If you're talking federated login, that's what OIDC is for. If you're talking "login", your opinion is misguided.
Sorry, but following a standard for federation is not a substitute for building a log in system, which is what most people want when building "a web app".
The blog posts and discussion was long ago (the video is 6 years old). Since then, that particular author acknowledged that (iirc) OpenID Connect solves many of the things he criticized. I have to look up the source, it’s been a while.
However, OIDC and OAuth2 are complex protocols which is also why we encourage most greenfield and small projects to avoid it unless explicitly required.
It’s also important to note that that particular person voiced criticism, but most of the biggest names in tech (GCP, AWS, ...) heavily rely on those protocols (+ extensions). His proposed alternative protocol Oz never got to real world adoption (to my knowledge) and has recently been archived. The prediction that we would see major OAuth2 security wholes within 3 years (so 2015j never came true. It doesn’t mean that he was wrong, but that there are opinions that contradict him, and that those opinions and voices have established themselves in the industry.
Yes, implementing both OAuth2 as well as OIDC according to spec is a significant development effort and countless teams and companies fail at pushing through, shipping incomplete or insecure implementations. If you’re greenfield, OAuth2/OIDC is with 99% certainty not the right fit for you anyways.
It leaves the implementation of the login (enter /password, ...) and consent (may application X have access to your pictures?) flows up to the developers using HTTP Redirection flows. You can therefore integrate it much easier in existing applications.
Also, you have complete control over the ui and user experience and must not learn a template language (Keycloak) or fork (Dex) the project to customize it.
Compared to Keycloak, Hydra is much more lightweight (no JVM/JBoss). However, you need to implement the user database yourself and/or write your own connector for it.
- https://oauth.net/articles/authentication/
- https://tools.ietf.org/html/rfc6749 - The OAuth 2.0 Authorization Framework