Javascript not secure anymore for Delivery Api protected content?

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 :laughing:

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.

3 Likes

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!

Hi @kjac , I’m trying to create a similar solution to your example, but based on oidc-client-ts.

However, I’m running into the problem that when I try to call ‘/umbraco/delivery/api/v1/security/member/userinfo’, I get a 401 error. I’ve also tried this with the project in your article, and then it also happens, even though cookies are sent with the request.

Do you have a tip on what adjustment I could make to make this method also work for the userinfo endpoint?

I see an OpenIddictServerEvents.ExtractUserinfoRequestContext event, but the context.Request object is empty when I debug this event. Any idea where the token can be swapped?

I’ve now discovered the reason why the ProcessAuthenticationContext event isn’t working for the UserInfo endpoint. EnableUserInfoEndpointPassthrough is included in the Umbraco OpenIddict configuration. This causes OpenIddict to leave the UserInfo endpoint untouched, so these requests aren’t processed.

For this reason, I’ve added a small middleware handler to the HideMemberTokensHandler. Admittedly, it’s not very nice that HideMemberTokensHandler also serves as middleware, but it does reduce duplicate code.