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.
I have wasted so much time on oAuth2 and OIDC the past month that I'm building a SaaS around it. (not wasted but took away time from the business)<p>I would have really liked to use auth0 or other authn services but not a fan of lock-in platforms, I want to export my db without enterprise plans.<p>The pricing model I'm thinking of is a pay per usage + a commission of the total usage per month.<p>Thank you @sjroot
For those who are looking for an alternative and are OK with <i>centralization</i> of Auth which is somewhat different from the goals of OAuth, check out the CAS standard -- it's an alternative to SAML more so than OAuth.<p>It's so simple I wrote (and abandoned) a golang library that implements v1[2]. I didn't need the proxy abilities in v2 (and doubt most orgs actually do) and I use JSON in some places before it was in the standard but it was very easy to implement and thus I can say it's easy to understand. I've meant to convert the project to Rust for a long time but at this point I'll probably never get to it.<p>[0]: <a href="https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Specification.html" rel="nofollow">https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol-Spe...</a><p>[1]: <a href="https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html" rel="nofollow">https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.htm...</a><p>[2]: <a href="https://github.com/t3hmrman/casgo" rel="nofollow">https://github.com/t3hmrman/casgo</a>
Are you implementing OAuth 2 or interested in learning more? I would <i>highly</i> recommend combing through the OAuth 2.1 spec [1] as it incorporates the “best practices” that were added to 2.0 through additional RFCs.<p>[1] <a href="https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00" rel="nofollow">https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00</a>
May be worth mentioning--JWTs are not part of the OAuth. They're certainly used together quite a bit, but you can absolutely use regular session tokens too.<p>I say this as someone who thought JWT was a core part of OAuth and it only added to the perceived complexity of the implementation.
The one thing that really bugs me about the OAuth flow is what is described as step 3. When the application who wants to access data on your behalf is redirected to a login page where the user enters credentials and grants access.<p>In many apps, these login redirects happen inside the app window, hiding the url. And even if the URL isn’t hidden, there’s suddenly a browser window inside my app and many unconscious “security checks” fail to load.<p>I’d much rather have the OAuth provider send me an email or get a notification that can be actioned within the OAuth providers app so that I know I’m not giving my credentials to something that looks like the OAuth providers sign in page.
This was a really well-written post. I really liked the learn by doing approach accompanied by flow diagrams. It's easy to get lost in the weeks with OAAuth terminology and this really kept good focus. I also looked at some of the author's other posts on things Protobufs and Tries and found them similarly enjoyable. I look forward to reading future posts and hope you post them here as well.
The article briefly mentions that the Implicit Grant is a less secure and more simplified version of the Authorization Code grant, but then it doesn't elaborate (or it's possible I missed that bit). In an introductory article such as this, I think it's important to explain <i>why</i> it's less secure -- otherwise the Authorization Code grant seems like an unnecessary complication.
Would you think that, for an early-stage SaaS startup (enterprise B2B focus), the <i>optimal strategy</i> for implementing AuthN/AuthZ would be to use a managed service (e.g., Auth0) for MVP development and after that (perhaps, during pilots phase) migrate to an open source solution (e.g., Keycloak)?
The main confusion probably comes from the name Oauth, which seems to suggest that it is about Single Sign On/authentication, while in reality it's about granting site A access to your data at site B.
Can we update the link to point to the actual article?<p><a href="https://www.polarsparc.com/xhtml/OAuth2-OIDC.html" rel="nofollow">https://www.polarsparc.com/xhtml/OAuth2-OIDC.html</a>