The issue isn't the process of creating sessions. The API is already optimal in that regard (in that sessions are lazily started, the first read or write access to the session API will trigger a session start). The real issue is basically how core is reliant upon information about the active user to configure a vast number of features in the earliest parts of the application's execution cycle. For the admin application, the session is effectively started here and the frontend application here. The admin side isn't as much of an issue, or really the frontend if using shared sessions, but the frontend path is a bit of an issue as it's basically impossible to at least reach the onAfterInitialise event (even if you get past that first line I pointed out, there are still a couple of calls into the plugin helper that also rely on the session, then a couple other spots in the parent class' initialiseApp method that also directly or indirectly trigger a session call. Once you get past that it looks like the application classes are clear of session interactions until the components are dispatched, at that point it's up to plugins to behave politely as far as your sessions go.

It's really surprising that the API is not using the most common way for sharing tokens with the front end: JWT. Also should be very low effort as there are quite a few packages already out there: https://packagist.org/packages/lcobucci/jwt?query=jwt

@dgrammatiko JWT means Json Web Tokens, right?

Yes

The API authentication mechanism has nothing to do with the core application workflow and inherently the manner in which sessions are essentially mandatory, please use another issue for that discussion.

Meh, I wan't open a new issue because whenever I come up with anything that criticises other ppl work it always interpreted as a personal attack. Let it be...
By the way the only reason I commented here is due to my stupid idea that session is tightly coupled to Auth. (I mean what's the reason syncing the front end with the back end if the user is not authenticated? rhetorical question)

One last comment here. @astridx is right in the other PR that a prefix is needed. The reason is security check Joomla.org with https://observatory.mozilla.org especially the cookies section. If that calls for a rethinking also of the sessions (greater scope, I would like to see no sessions for guests) then this issue is valid. Anyways the other one is a low hanging fruit that should be fixed in J4.

My 2c

Prefixed or not should still be user configurable. Not an arbitrary decision by the platform, definitely not a hardcoded string, and definitely not in a spot in the API that it screws with the rest of the configurable portions of the session API.

By the way the only reason I commented here is due to my stupid idea that session is tightly coupled to Auth.

It is, but this isn't a "if you could write the Joomla Session API from scratch today how would you do it" type of issue. Truthfully, the session API behaves just fine as its own element within the greater application. The entire problem with sessions boils down to the Joomla application design, not a flaw in sessions (and FWIW with the current architecture it wouldn't really matter if the API application used JWTs or Basic auth or OAuth or any other thing, the same architectural flaws are present which is why I'm saying the JWT bit just doesn't belong here). Basically, core features of Joomla are extremely tightly coupled to the active user, and just to be able to configure the application to work in the currently designed state, it forces a session read, and said session read will force a session start (because the session API is rightfully designed for lazily started sessions (the API automatically starts the session on the first call to any of the read/write methods instead of forcing someone to put an explicit $session->start() line in), even if the rest of the application isn't).

Prefixed or not should still be user configurable

I'll say there's little gain making it configurable, IMHO and reading the specs it should be either __Host or __Secure (someone needs to check which one best fits Joomla)

the same architectural flaws are present which is why I'm saying the JWT bit just doesn't belong here

I will agree on that, my comment was a bit stretched. Probably I should keep those comments to myself but for some awkward reason I still care...

Prefixed or not should still be user configurable

I'll say there's little gain making it configurable, IMHO and reading the specs it should be either __Host or __Secure (someone needs to check which one best fits Joomla)

Those prefixes honestly I'd say should be configurable in the session API too, but maybe in the application it's just not exposed and defaulted to on (remember 4.0 is using a standalone library now for sessions, said library shouldn't be littered full of Joomla application design quirks). The application prefix suggested in the original PR, on the other hand, I'd say should be 100% configuration based (as you're (legitimately) changing the logic used to generate session names and inherently cookie names; I don't see the reason that part of things needs to be a hardcoded prefix or a totally fixed string in general on every Joomla website).

I think the implementation details could be ironed out same goes for the update procedure. My point was that if you're about to do such changes then you should follow the specs and prepend __Host- for http requests and __Secure- for https. And that would be driven from increased security, reduced attack surface, etc and not some random requirement I want my tokens to be identifiable through some prefix. I'm not pledging for that, just to be clear here.