Your description is almost correct. To be clear, here's an accurate description of the flow:
1. The user clicks on "Signin with Facebook", which triggers an endpoint in Spring Social's ProviderSignInController.
2. ProviderSignInController redirects the user to Facebook's **authorization** page. If the user has not yet signed into Facebook, then Facebook will prompt them to sign in. After signing in, they will be asked to authorize your application to access Facebook on their behalf.
3. The user authorizes your application at Facebook and then Facebook redirects back to your application at an endpoint that is handled by ProviderSignInController.
3b. If the user has previously authorized your application, they will not be shown the authorization page at all and Facebook will immediately redirect them back to your app.
4. If the user has previously created a connection with Facebook (via ConnectController), then the user will be signed into your application. The actual signin takes place via an implementation of SignInAdapter.
4b. If no previous connection matches, then the browser will be redirected to a registration page. After the user registers with your app, a connection will be created for future use.
The key thing is that it's actually Facebook *authorization* that takes place, but a pseudo-authentication is performed at the end of that authorization. This is demonstrated in Spring Social Showcase.
An alternate flow is one where there is no previous connection (step 4 and 4b) and instead the user's info is retrieved from Facebook and used as the user record. This is roughly what takes place in the Spring Social Quickstart.
Spring Social Project Lead