I enjoyed this, we definitely made some of these pitfalls in my past startup. The example about needing to check the audience before requesting resources is a good one.
OAuth2 is impossible to use outside of the "give a third party service access to your Facebook photos" use case.
Imagine you're using LDAP for authentication and authorization for some internal LAN apps -- maybe gitea, zulip, paperless. Users can present the same credentials to all your apps but they'll have to authenticate with each app they use. For authorization, the apps can query your directory for a users' group membership for am RBAC. The main drawbacks of this scheme are that it lacks SSO like you'd have with kerberos or OIDC, and the apps may need more access to the LDAP directory than is required to strictly authorize/authenticate a user -- every app gets to handle user passwords, and 2FA would be difficult to retrofit.
Now if you install keycloak, users can authenticate to keycloak's login page, and keycloak will proxy this cookie to the apps which no lo longer need to handle passwords or 2FA. OIDC is an all round improvement, we've centralized authentication, hardened it with 2FA, and avoided wearying the user with superfluous login prompts.
The problem here is that though we've centralized Authentication, authorization remains uncentralized, implemented in different and unmanageable ways for each app. If we have 70 apps and want to audit what permissions each app will grant a particular authenticated user, it would be ideal if we could query a centralized directory like we could with LDAP. But in practice we'd have to parse the config files and database tables of all 70 apps.
I've been reading on OAuth2 to see if refactoring an app would allow me to use keycloak/zitadel/ory to centralize the authorization, the ACLs, and the group membership. This would be a huge win for a next-gen authorization protocol... But the "Facebook photos" use case is so dominant that there doesn't seem to be any reasonable path to having an Oauth2 server with the same utility for a small org that an LDAP server already provided 25 years ago.
> 1. Being a consumer of OAuth2/OpenID Connect: you implement "Sign in with Google," need access to a user's GitHub account, and other use cases. Here, OAuth2 makes a ton of sense. This article does not cover this use case.
> 2. Being a provider of OAuth2/OpenID Connect: You want to become the system that issues OAuth2 Access Tokens, OpenID Connect ID Tokens, etc. This article is for you!
