Understanding OAuth2 and OpenID Connect
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&#x27;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&#x27;t use implicit flow, use the authorization code grant with PKCE.<p>* Don&#x27;t use resource owner password flow; it was designed to allow existing systems to bridge into OAuth and shouldn&#x27;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&#x27;s a post I wrote about it: <a href="https:&#x2F;&#x2F;fusionauth.io&#x2F;blog&#x2F;2020&#x2F;04&#x2F;15&#x2F;whats-new-in-oauth-2-1" rel="nofollow">https:&#x2F;&#x2F;fusionauth.io&#x2F;blog&#x2F;2020&#x2F;04&#x2F;15&#x2F;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&#x27;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.