Indeed, I see so BC path to add the nullable type to the interface.
Maybe there's no need to change anything and you can pass a user with no roles instead?

We could introduce a class that decorates the existing one with a different signature and creates such an empty user when forwarding the call. Or maybe another helper in AbstractController doing this might also ease things?

Such a method could also be placed in the Security class in SecurityBundle.

@aschempp there is one more possible option, to make Guest user a separate class, which implements Userinterface too. But it may require a lot of changes in legacy systems.

Given the purpose of this method and the fact that one aim of the now well-established authenticator system was to remove the concept of unauthenticated tokens (see e.g. #42050 and #42510), I don't think we should try to address this here, passing some kind of null user on the caller's side seems good enough.

passing some kind of null user on the caller's side seems good enough.

That would be perfectly fine with me. But shouldn't the security system then return such a null user in e.g. SecurityHelper::getUser() as well? Which certainly would be a BC break as well 😅

As an example of our current system (Contao CMS), we have permissions on objects that can be given to certain user groups, or to guests. Our voters then decides whether there is a user in the current system and which groups it belongs to, or if the object is allowed for guests. If there's a new NullUser concept, we'd need to adjust all voters to check for ->getUser() === null || $user instanceof NullUser which feels kinda wrong?

Btw. would you consider this a bug (to be fixed in 7.3 possibly) or a feature to check for guest users?

The most backward and forward compatible solution might be to create a new UserAndGuestAuthorizationCheckerInterface that accepts a null object. We could then deprecated the other interface …
Since most applications will probably use the core AuthorizationChecker, everyone could instantly use the new method instead of the deprecated old one.

Let me know if you like that idea, I can then update the PR (we can still decide on final naming later).