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.<p>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).<p>Additional things that I wish had been in the article:<p>* Don't use implicit flow, use the authorization code grant with PKCE.<p>* 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.<p>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: <a href="https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1" rel="nofollow">https://fusionauth.io/blog/2020/04/15/whats-new-in-oauth-2-1</a><p>* 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.<p>* 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.