This is reasonably simple to support in the ProviderSignInConroller flow (e.g., pre-signin, post-signin). Where it gets tricky is in the case where no matching connections are found and the flow turns from being a sign-in flow to a sign-up flow. At that point, ProviderSignInController hands things off to an application-defined signup page along with a ProviderSignInAttempt to complete a connection after the signup is performed.
In that case, it's completely up to the application to handle the signin after signup and to handle the post-signup connection (via SignInAttempt).
One option is to pass the list of interceptors along with the ProviderSignInAttempt. But this creates a potentially nasty situation carrying a list of interceptors around in a session attribute. I'm not particularly fond of this option.
The other option is for the interceptors to only participate in the ProviderSignInController flow and leave any post-signup behavior in the purview of the application's own post-signup code. I favor this approach as it's cleaner from a Spring Social perspective. But I also favorite it because there's no reason to pass around some interceptor in session so that application code can call it after signup when the application code can just implement that post-signup code on its own...the ProviderSignInAttempt object has everything it needs to do post-signup logic with a connection.
For now I've addressed the interceptor issue within the scope of ProviderSignInController's signin flow with a new ProviderSignInInterceptor that includes preSignIn() and postSignIn() methods.
With that, I will now mark this issue as resolved. If there's a need for additional interceptor events to be handled in ProviderSignInInterceptor, I ask that you open a new improvement issue to address the specific interception case you have in mind.