Hi,
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?
Hi @mcl-sz
Goodness. I added that section to the docs just this morning. News travel fast 
First and foremost - don’t panic. The new recommendations from IETF are still in a draft state. But we anticipate them to be adopted… and so does Microsoft, as you can read in their OIDC configuration guidelines.
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.
Thank you so much for the explanation @kjac ! In the meantime, I’ll also delve into it backend for frontend authentication.
Hi again,
The article I teased earlier is now live: https://kjac.dev/posts/secure-member-auth-for-the-delivery-api/
Hi @kjac,
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!