Clarify cookie auth usage and future

[enkelmedia]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

14.2.0

Bug summary

I'm working on something that needs to check if the user is currently logged in to the backoffice from places outside of the backoffice. Some parts are also used inside the backoffice (so some kind of a hybrid-thing). This feature, that used to work on v13, uses the backoffice cookie configured for Umbraco.Cms.Core.Constants.Security.BackOfficeAuthenticationType to check if the current request comes from a backoffice authenticated user.

I've shared a snippet here that is similar to what I currently do: https://our.umbraco.com/forum/umbraco-9/106857-how-do-i-determine-if-a-backoffice-user-is-logged-in-from-a-razor-view#comment-334423

After moving to v14 it seems like this cookie is more or less not used by the backoffice anymore? After manually removing the cookie, the backoffice still works as expected and I'm not "thrown out". I know that the Management API uses a bearer token for auth, but the cookie is still set during login which makes it kind of tempting for me (an possibly other developers #17358) to use this cookie.

There are a couple of potential issues here:

• As far as I understand this cookie is only renewed on a full page reload. If something inside the backoffice rely on the cookie it could timeout if the logged in editor is using the backoffice for a long time (keeping tab open etc) without reloading.

• When working on localhost it's common to run different sites on that hostname. If I start another site (e.g. a Umbraco 13 website) on localhost and login, this will overwrite the cookie. When going back to v14, nothing will notice this and the "thing" that rely on the cookie will not work. Not even after a page reload.

I'm kind of wondering if this cookie is just a left over from the past? At the same time, we have some nice use cases for this cookie, for example using it for test/stage environments so that we can force a backoffice user login before allowing someone to access the site. Without the cookie we would not be able to know that they are logged in.

So I guess the answer to the question about the future of this cookie will dictate of this is something that should be addressed or if I need to look for another solution. I've notice in the core-code that @kjac wrote some of the stuff around this, maybe you know more?

Cheers!

Update:
It came to my mind that @nul800sebastiaan's great Hangfire-dashboard uses the same technique and would probably suffer from the same issues.

https://github.com/nul800sebastiaan/Cultiv.Hangfire/blob/bellissima/Cultiv.Hangfire/UmbracoBuilderExtensions.cs

[github-actions[bot]]

Hi there @enkelmedia!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[nul800sebastiaan]

I'll just link this to nul800sebastiaan/Cultiv.Hangfire#37 - yes I have a problem with cookie auth as well 😅

[nul800sebastiaan]

I had a chat with @kjac as well and I forgot exactly what conclusion we came to but I think it was some filter in the routing pipeline that I would need, correct Kenn?

Not sure if that applies to your use cases though, since it looks like you don't have 1 predictable route pattern like I do. Perhaps you can do something with a bearer token? Not entirely sure what your use case is!

[enkelmedia]

I kind of have multiple use cases =D

One of them is the "lock out screen" that where we basically check for the backoffice cookie and login the user if they're not already logged in.

Another is similar to yours where I'm rendering something inside a iframe. For this scenario that I'm working on (basically statically rendered HTML inside a iframe) I'm currently looking at using the srcDoc-attribute of the iframe element - basically fetching the HTML from a bearer token authed endpoint and render it.

I guess that it's not super uncommon for someone to want to render a iframe that uses something similar to your Hangfire-thing but that maybe requires navigation inside the iframe - in that case srcDoc would probably not be a viable work around.

[nul800sebastiaan]

I think I tried that as well, but I don't think it helped, since there's css and is links in the iframe that need auth as well. Not sure if I tried srcDoc specifically though!

[nul800sebastiaan]

Just remembered; yep that's exactly what I tried, and it's not a feasible path. Indeed because of clickable links in the iframe and references to css and is files that fail too.

[kjac]

Quick comment from my part 😄

The auth cookie should not be used for anything other than the core login process. It is solely there to make the login screen work. Indeed, if you use external login providers for the backoffice, I am actually not even sure it's ever set, because it's really not necessary for the login process to complete.

[enkelmedia]

Thanks for the info @kjac!

I guess then the question would be: What’s the recommended approach in a situation like this?

Could really be about anything that needs to be protected and only shown for logged in Users. Not sure if @rsoeteman is using any of this for Media Protect?

[enkelmedia]

Just adding a little more context here,

We have another feature in older sites where we will show a ”edit button” on the front end that links to the backoffice so that editors can navigate to the right node in a nice way. This would also require some way of knowing that the visitor is logged in to the backoffice.

Would it be possible to create a specific cookie for these kinds of use cases maybe?

Or maybe move the API token into a secure cookie so that it’s not extracted by some XXS code in the backoffice.

[kjac]

Hi @enkelmedia

Long story short: We can't support this out of the box. The login cookie from core should never be used for other purposes.

We're currently investigating options here for scenarios like yours. @nul800sebastiaan and I have found a path forward, but we need to iron out a few kinks before we can share a solution.

[enkelmedia]

Thanks for the update @kjac! :)

I think it would be valuable if there was a clear path to supporting something like this (or a ”offcial way” of doing it, I know that the snippet that I shared in the forum has been used (and improved) by others so there is a real need to be able to know this on the frontend in a reliable way.

[kjac]

Hi again.

Long story short it's not terribly viable to rely on the core auth cookie. For all intents and purposes I would consider that to be an internal mechanism, not something to piggy-back custom auth requirements on top of.

I have outlined another solution in this blog post.

It entails going straight to the OpenID Connect framework (OpenIddict). We could potentially consider building official Umbraco extension points to achieve the same thing, to hide away the concrete technology.

[enkelmedia]

Thanks a lot @kjac for outlining a potential approach! 🚀 I've been thinking in the same lines but kind of stopped and posted this issue since I think that this is something that should be managed centrally in some way.

If it would be up to each package developer to implement this, end users would have X cookies essentially doing the same thing.

One idea could be that something in Umbraco is capable of creating this "frontend-backoffice-scheme" and manage the cookie etc. so that all packages (and site specific extensions) could use the same underlying thing. Maybe this feature could be turned off by default and provide some way to a extension to active it if needed, this way if any extension activates it - others could reuse it.

I understand if this is kind of a niche thing but still wanted to outline my "dreams" around it 😀

[kjac]

Hiya @enkelmedia

It could also be a package idea for the community 🤞

I'm trying to convert this to a discussion, as it is essentially a feature request by now. Unfortunately GitHub is not playing nice, so... apologies if you get a ton of notifications 🙈

[nul800sebastiaan]

I don't really see a problem with packages adding additional cookies, I'm actually quite relieved that now I'm in control of that cookie, what I put in there and what the cookie properties are.

For example, most people can make it HttpOnly, and then automated security scanners don't start flagging "insecure cookies" (they don't know what they're talking about). But most of these cookies probably don't need to be available to scripting. The "system cookie" should not cater to the lowest common denominator, so it has to be HttpOnly enabled.

Anyway, all I'm trying to say is: would be great if there's a standardized solution, but I also enjoy setting my own cookies.

IMO: if the core of Umbraco is not using it, we should probably not be providing it. I also keep thinking of 80/20 rule: if 80% of our users is not going to use it, should it be in the product? So yes, would love a package. 😁

[kjac]

I tend to agree, @nul800sebastiaan

Also, GH refuses to convert this issue to a discussion. Oh well. Maybe next week 🤷