Both types of successful authentication events (AuthenticationSuccessEvent AND InteractiveAuthenticationSuccessEvent) are fired BEFORE the session fixation protection migrates the session data. This is INVALID, as the session ID contained within the data provided by the event is no longer valid immediately after the event completes processing.
So, for example, one cannot use ApplicationListeners for AuthenticationSuccessEvent and SessionDestroyedEvent to maintain a log of login/logout activity, because the session ID changes between when the success event is called and the destroyed event is called.
There was a discussion about this in the Spring forums (attached). The conclusion reached in this discussion is, I believe, also invalid. Spring Security classes shouldn't have to be overridden in order to make them behave correctly. It seems a trivial matter for the authentication event to be called AFTER the session has been migrated, which would provide accurate information in objects provided, through events, to a consuming application.