Thanks for pointing this out. Many providers redirect back to the callback URL when the user denies authorization. This is certainly how Twitter, Facebook, LinkedIn, and Google (OAuth 2) behaves. But since ProviderSignInController didn't have any handler methods to handle GET requests for /signin/{providerId} where there isn't either a code parameter or an oauth_token paramer, you'd get an HTTP 405 response when that callback happened.
I just pushed a new snapshot built with an improvement to ProviderSignInController to handle that callback by redirecting to the sign in page ("/signin" by default, but configurable through ProviderSignInController.setSignInUrl() ). That seemed to be the most appropriate response in this case as it would once again offer the user an opportunity to sign in to the application through other means (another provider or username/password).
Try it out and let me know how it works for you.
Craig Walls
Spring Social Project Lead