[Security] A matter of authenticators, firewalls, stateless AND stateful authentications #45025

gnutix · 2022-01-14T10:10:52Z

gnutix
Jan 14, 2022

Hello there! :)

I'm currently migrating our Guard security classes to Symfony 5.4's new Authenticators and am having trouble finding a proper way to do what I need. There are 2 ways (currently, more coming) to authenticate a user in the application :

Filling a login form that uses json_login, which should produce a stateful authentication (re-usable across multiple requests using the session and a cookie)
Using a Device Token in the Authorization header, which should produce a stateless authentication (non re-usable, must be provided for each requests) and represents some kind of "anonymous" user (in the sense that it's not an actual user "entity").

And there are the following routes patterns :

/api/sign-in/* : must be public, used for the login form
/api/* : must be secured, but some are restricted to requests having an Device Token, some can be access if you have a stateful authentication (cookie), and some can use either of both authentications
/* (any other route of the application) : must be secured, only using stateful authentication (cookie)

And finally, only one main firewall (without any specific options like stateless, pattern, context or else).

PS : In /api, there are both Symfony routes and "legacy" routes (using mostly Slim, others plain PHP, routed through a LegacyController - kind of like this, but not exactly..). Prior to this Guard => Authentication migration, the "Device Token" authentication was done solely in the legacy code (completely outside of Symfony's Security system), which means Symfony had no idea the user was authenticated on those routes (through the Device Token). Now that there is an Authenticator for it, Symfony knows.

So looking at the doc, I thought : OK, let's create two firewalls, one stateless for the devices with pattern: ^/api and the other one stateful with the json_login auth without pattern, and share the authentication using the context option. Except...

The firewall context key is stored in session, so every firewall using it must set its stateless option to false. Otherwise, the context is ignored and you won't be able to authenticate on multiple firewalls at the same time.
https://symfony.com/doc/current/reference/configuration/security.html#firewall-context

So I can't use context and stateless simultaneously, which means when a user has logged in using the login form and has a stateful authentication, when he loads any page that does AJAX calls to /api/{whatever} (without providing a Device Token), he won't be considered logged in as this route will match the stateless firewall and his stateful authentication won't be recognized...

I know of one "proper solution", which would be to add a new Authenticator to the stateless /api firewall that would use a JWT token (or something similar) to say "hey, I'm user X", that the frontend would have to provide everytime it calls an /api route. But that's a lot of efforts, as the frontend completely relies on the user's session's just "being there"... Same for functional tests.

Currently, I've found a hack to make the Device Token authenticator "stateless" (even though the firewall is stateful) using a kernel.response event listener with priority 1 (just before Symfony\Component\Security\Http\Firewall\ContextListener at 0) that sets $event->getRequest()->attributes->set('_security_firewall_run', 'hacked'); only when the user has been successfully authenticated using the Device Token Authenticator.

This way, ContextListener::onKernelResponse() is skipped (because it checks _security_firewall_run against the firewall name at the very beginning and returns early if they don't match), which effectively prevents persisting the token in the session altogether, making it "stateless".

I'm not really proud of this hack though... But I'm kind of stuck between a "short term gain" (one line of code fixes my problem : one stateless authenticator in a stateful environment) VS "long term gain" (having a new authenticator and adapt the frontend, which is probably weeks of work for both a backend and frontend team, with a cleaner API in the end).

Would you folks have any other suggestions ? Cleaner ways to prevent Symfony from setting the Set-Cookie header, or other ways to configure the firewalls ? Why is stateless tokens (instead of stateless firewalls) not a standard option from the Security component (knowing it "works" - in our use case at most - with one line of code) ?

Thanks for your insights.
gnutix

jasperweyne · 2023-01-16T13:11:37Z

jasperweyne
Jan 16, 2023

Hi,
I've been looking in to this as well, since I have a similar setup where one form of authentication (Bearer tokens) shouldn't be persistent across multiple requests, while another form of authentication should be (form login), but I want my API to understand both.

Another way of accomplishing that behaviour would be to remove ContextListner::onKernelResponse from the dispatcher altogether, eg.

$dispatcher->removeListener(KernelEvents::RESPONSE, [$contextListener, 'onKernelResponse'])

This would require the contextListener to be manually wired in with an explicit definition in services.yml. For my use case, I want to configure this stateless behaviour in the onAuthenticationSuccess methods for the "stateless" authenticators. Since Request is provided there anyways, I considered the solution you described to be best for me. However, removing the whole event listener may be considered somewhat "neater".

Hope it helps!

1 reply

gnutix Jan 16, 2023
Author

Thanks for sharing your thoughts!

I'm g 8000 lad to hear my hack worked for you too, though I'm sad to imagine it spread to many code bases without a proper fix being addressed.. ;/

gnutix · 2023-08-29T15:17:50Z

gnutix
Aug 29, 2023
Author

Looking at Symfony 6.3.4's changelog and seeing #51350, I hoped it would fix this issue... but it does not. The nasty hack is still needed. :(

0 replies

micheh · 2023-12-31T12:08:30Z

micheh
Dec 31, 2023

I have the same use case where an API should accept both session based authentication and stateless token based authentication.

Maybe a marker interface like StatelessToken could be added if a token should not be persisted. If someone authenticates using a stateless token (e.g. Bearer ...), the authenticator creates a Token instance which implements this interface in the createToken method. The ContextListener will see that the token should not be saved in the session and does nothing.

symfony/src/Symfony/Component/Security/Http/Firewall/ContextListener.php

Line 167 in ccbdc1a

$token = $this->tokenStorage->getToken();

if ($token instanceof StatelessToken) {
    return;
}

0 replies

ahmed-bhs · 2024-02-28T13:11:11Z

ahmed-bhs
Feb 28, 2024

Hi @gnutix

Thank you for raising this issue. I'm curious if you have any suggestions on how to bypass the Context Listener in Symfony 3.4. I've observed that the _security_firewall_run attribute isn't being set.

https://github.com/symfony/symfony/blob/v3.4.49/src/Symfony/Component/Security/Http/Firewall/ContextListener.php#L136

Perhaps we could invalidate the session and adjust the priority of our new listener to -1?

    public function onKernelResponse(FilterResponseEvent $event)
    {
        if (0 < \count(\array_filter([
            JWTUserToken::class,
        ], function ($entry) {
            return $this->tokenStorage->getToken() instanceof $entry;
        }))) {
            if ($event->getRequest()->hasSession()) {
                $event->getRequest()->getSession()->invalidate();
            }
        }
    }

1 reply

gnutix Feb 28, 2024
Author

No idea, sorry. Symfony 3.x has been EOL for years... It's not even on the release map graph anymore, you might really want to try to upgrade your version.

Uh oh!

[Security] A matter of authenticators, firewalls, stateless AND stateful authentications #45025

Uh oh!

Uh oh!

gnutix Jan 14, 2022

Replies: 4 comments · 2 replies

Uh oh!

jasperweyne Jan 16, 2023

Uh oh!

gnutix Jan 16, 2023 Author

Uh oh!

Uh oh!

gnutix Aug 29, 2023 Author

Uh oh!

Uh oh!

micheh Dec 31, 2023

Uh oh!

Uh oh!

ahmed-bhs Feb 28, 2024

Uh oh!

gnutix Feb 28, 2024 Author

gnutix
Jan 14, 2022

Replies: 4 comments 2 replies

jasperweyne
Jan 16, 2023

gnutix Jan 16, 2023
Author

gnutix
Aug 29, 2023
Author

micheh
Dec 31, 2023

ahmed-bhs
Feb 28, 2024

gnutix Feb 28, 2024
Author