For the most part, Spring Social does *not* use sessions. It does create request-scoped beans on occasion, but since those are request-scoped, they are effectively stateless (that is, they don't survive the current request).
But ProviderSignInController and ConnectController may put a few things in the session. For OAuth 1, the request token may be kept in session. And for ProviderSignInController, when the authentication has failed, a pending connection will be kept in session so that the app can create a session after the user has registered with the site.
I suppose that in the latter case, there could be a setting that disables that--effectively saying that you have no intention of creating a connection after registration. I could consider making that work. If that would be useful for you, may I suggest that you create an improvement issue in JIRA for this and I'll consider it.
In the former case, I know of no way to reliably carry the request token without putting it *somewhere*. It can't be carried as parameters in the request for many reasons (security being one of them, the likelihood that the provider would drop it in the redirect being another). If I don't put it in session, I could place it in a key-value store like Redis...but that would still be server-side state carried between requests, no different than session.
Spring Social Project Lead