Started a long time ago with this branch, so I thought it was time to create a POC PR to get the opinion of core teammembers and contributors on this topic.

NOTE This PR is just to give an insight in the idea. Please don't review the details (e.g. the version numbers in deprecations), I know there is work left to do 😄.

The Story: Removing UserInterface

The Security system currently manages users with 2 types of classes: UserInterface and TokenInterface. The devs using Symfony most of the time end up using UserInterface as their user object in the application. This has some drawbacks:

• You're forced to implement methods you never need to use (getPassword(), getSalt(), etc.) ([Security] getUsername in UserInterface is confusing #10316)
• The complete application user object will be serialized in the session
• You need to configure the serialization of your application user (http://symfony.com/doc/current/security/entity_provider.html#understanding-serialize-and-how-a-user-is-saved-in-the-session)

Probably more than a year back, @iltar, @weaverryan and me had a discussion about this on IRC. A nice idea was born there:

• Make Token the first-class citizen of the Security system. All information that the security system needs to know about the user should be saved in the token.
• The Token will be serialized in the session
• There still is a user/identity object in the token, to allow the very conventient getUser() method and app.user var. This user object should have a getIdentifier() method, returning an identifier for the user which is saved in the serialized token.

This Pull Request

In order to store all security information in a token, the token needs to be split into 2 seperate tokens: Authentication request tokens and Authenticated tokens. The authentication request token contains all information before authenticating (such as the username and password passed through the login form). The authenticated token contains the identifier (see previous section) of the logged in user and the roles bound to this token.

Splitting the token also has other major advantages:

• The weird "user has to be a string, UserInterface or object with __toString()" thing in the security system is removed. Users are now always an object instance of UserInterface in authenticated tokens.
• The 2 types of tokens are actually very different. It doesn't make much sense to use the same class to represent them (e.g. unauthenticated tokens don't have roles, there is no concept of user in unauthenticated tokens, etc.).

The Future

In follow-up pull requests, the rest of the story of removing the UserInterface can be done.