Consider reviewing the usage of `Authentication`

Spring Security should consider reviewing the usage of the Authentication Interface in regards to improving the usability of Spring Security outlined in #13266

Spring's Authentication interface deals with a multitude of issues, many of which I believe stem from its exposure to the downstream Developer, multiplied by its relatively long lifespan (Almost as old as yours truly!) The main one I'd like to highlight for review is the following, a solution to which was discussed in #14352

• Weak Typing within the interface, specifically getPrincipal() and its intended behavior within the Spring Security Architecture, being assumed to be an instance of UserDetails.

During a longer review of the downstream pain with getPrincipal(), I'd like to highlight another minor issue that could also be addressed.

• Excessive doubling of information between the UserDetails and Authentication, clouding responsibility.

For the main point I believe the fact the Javadoc states the following should be a good enough reason to review the type signature.

Many of the authentication providers will create a UserDetails object as the principal.

In order to not conflict with the overview statement of Spring Security , "Spring Security is a powerful and highly customizable authentication", a solution might also involve minor modifications to the UserDetails object to make it more flexible.

Regarding the minor point I believe a comparison of Methods within the UserDetails and Authentication Signatures can provide the context for it.

• UserDetails::getPassword to Authentication::getCredentials
• UserDetails::getAuthorities to Authentication::getAuthorities
• Principal::getName to UserDetails::getUsername
  This overlap results in what I can only call a "weird tuple". We need an Authentication to build a UserDetails, and 1/2 the Authentication is essentially useless until the UserDetails/Principal field is populated, at which point the Credentials are cleared, and the behavior of Authentication converts more to that of UserDetails. These two behaviors of Authenticating the User, and representing the User, within the same interface, make it hard to work with for anyone starting to get into Spring Security.

Start by reviewing the Authentication, UserDetails, and Principal interfaces described in the issue, along with discussions in #13266 and #14352. Define and document an agreed approach for separating authentication from user representation and resolving the weak getPrincipal() typing; completion requires a decided, implementable design.