This was a good article. The first section, explaining the reason why OAuth2 is a fit for certain data flow needs, was really strong. I liked the diagram of the flow as that made it clear what all the pieces were.

I think that if you need that separation between your resource servers and authorization server, the OAuth dance can be a bit complicated, you can just use a simple api key. But as soon as you start to allow outside access to your systems, I'd suggest using an OAuth server (disclosure, I work for FusionAuth, a free as in beer competitor to Keycloak, Gluu, etc).

Additional things that I wish had been in the article:

* Don't use implicit flow, use the authorization code grant with PKCE.

* Don't use resource owner password flow; it was designed to allow existing systems to bridge into OAuth and shouldn't be used in new systems today.

Both the implicit flow and the resource owner password flow are not part of OAuth 2.1--here's a post I wrote about it: https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1

* Also, storing access tokens should be done carefully in the browser (httponly, secure cookies is the best way). If you can't do that, then use a server side proxy to store the access tokens. Otherwise your access tokens might get stolen by code executing in the browser.

* OIDC is built on top of OAuth and has a standard set of claims. If you can get by on what OIDC defines, you can switch between identity provider implementations fairly easily.