I was reviewing the documentation on how to use the Delivery API with protected content.
I noticed a section that was recently added:
It is no longer recommended to use public OpenID Connect (OAuth) clients for web applications. If you want to use protected content from the Delivery API in a web application, consider adding additional layers of security.
Does this mean that using “AppAuth for JS” or similar clients is completely discouraged?
A backend-for-frontend (BFF) pattern with secure cookie based authentication is the recommended approach for web applications. Long story short, this approach removes the risk of access token theft and subsequent misuse.
Now - that is easier said than done. For existing web applications, it’s just not that simple to replace everything auth. Therefore, I am working up an article at the moment, describing how to retrofit existing web applications, without having to rewrite the authentication handling to any significant extent.
I expect the article to be out in a couple of weeks. I’ll throw a link here once it’s out.
Thanks for the insightful article you wrote. I had already looked at how this was resolved in Umbraco 17 for the backoffice, so I suspected a similar solution was possible for members. It’s a great solution because it significantly improves security and the client-side adjustments are minimal. Great!