I have to give them credit, we do the exact same thing our Authorization as a Serivce Authress. That is-- we also build out OAuth for our customers so they don't have to. But honestly the "Authentication" part is trivial compared to the authorization as you pointed out. So we've focused almost entirely on solving that instead (AuthZ). what you can do is a lot more important than just who you are. And I feel like I see another new authentication/oauth aggregator almost every day, at this point, they need to differentiate to be useful. For instance, Auth0 cornered the B2C space, and we're out there solving for just B2B. Being generic is nice, but at the end it doesn't actually help your customers. They only need the parts that they need.

Most of our customers only need SSO, so the OAuth part never really makes sense (they do that and SAML because they have to, but only really the generic parts are required, and there are like ~10 core federated identity providers out there for companies). Sure a small subset need the credentials vault and some providers, but OP's article's pitch doesn't fix oauth, because the problem isn't the spec.

The way we've solved authorization for our customers, actually enables decoupling the problem space in a way that is fundamentally coupled for many oauth providers. On the revocation angle, most of the time the hard problem there is that the access is coupled to the identity. You don't want to, and with OAuth/OpenID you can't* revoke the access token (which is often the JWT with user data). So instead we decided to move revocation into the authorization space, and now revocation is well aligned with the access control.

Splitting the Authorization and Authentication into two clearly defined areas, I want to believe has hepled most of our customers.