This was one of the "Future considerations" of#33558:

Drop the AnonymousToken and AnonymousAuthenticator: Anonymous authentication has never made much sense and complicates things (e.g. the user can be a string). For access control, an anonymous user has the same meaning as an un-authenticated one (null). This require changes in the AccessListener and AuthorizationChecker and probably also a new Security attribute (to replace IS_AUTHENTICATED_ANONYMOUSLY). Related issues:#34909,#30609

This new experimental system is probably a once-in-a-lifetime change to make this change.@weaverryan and I have had some brainstorming about this. Some reasons why we think it makes 100% sense to do this change:

• From a Security perspective,a user that is not authenticated is similar to an "unknown" user: They both have no rights at all.

• The higher level consequences of the AnonymousToken are confusing and inconsistent:

  • It's hard to explain people new to Symfony Security that not being logged in still means you're authenticated within the Symfony app
  • To counter this, some higher level APIs explicitly mark anonymous tokens as not being authenticated, see e.g. theis_authenticated() expression language function
  • The anonymous authentication resulted in theIS_AUTHENTICATED security attribute being removed from[Security] Use new IS_* attributes in the expression language functions #35854, as there was no clear consensus on what its meaning should be

• Spring Security, which is where this originated from, makes Anonymous a very special case:

  Finally, there is an AnonymousAuthenticationFilter, which is chained after the normal authentication mechanisms and automatically adds an AnonymousAuthenticationToken to the SecurityContextHolder if there is no existing Authentication held there.

  Note that there is no real conceptual difference between a user who is “anonymously authenticated” and an unauthenticated user. Spring Security's anonymous authentication just gives you a more convenient way to configure your access-control attributes. Calls to servlet API calls such as getCallerPrincipal, for example, will still return null even though there is actually an anonymous authentication object in the SecurityContextHolder.

• Symfony uses AnonymousToken much more than "just for convience in access-control attributes".Removing anonymous tokens allows us to move towards only allowingUserInterface users:[Security] deprecate non UserInterface users #34909

Removing anonymous tokens do have an impact onAccessListener andAuthorizationChecker. These currently throw an exception if there is no token in the storage, instead of treating them like "unknown users" (i.e. no roles). See#30609 on a RFC about removing this exception. We can also see e.g. theTwigis_granted() function explicitly catching this exception.

• To make the changes inAccessListener andAuthorizationChecker BC, a flag has been added - default enabled - to throw an exception when no token is present (which is automatically disabled when the new system is used). In Symfony 5.4 (or whenever the new system is no longer experimental), we can deprecate this flag and in 6.0 we can never throw the exception anymore.
• anonymous: lazy has been deprecated in favor of{ anonymous: true, lazy: true } This fixes the dependency onAnonymousFactory from theSecurityExtension and allows removing theanonymous option.
• IntroducedPUBLIC_ACCESS Security attribute as alternative ofIS_AUTHENTICATED_ANONYMOUSLY. Both work in the new system, the latter only triggers a deprecation notice (but may be usefull to allow switching back and forth between old and new system).

cc@javiereguiluz you might be interested, as I recently talked with you about this topic