SocialAuthenticationFilter sample forthcoming

[habuma]

There has been a great deal of interest in the new SocialAuthenticationFilter (SAF) work that was started by Yuan Ji and that I'm now polishing and preparing for a milestone release (hopefully this week). I've received many questions about it, including several via private email.

Understandably, this is a popular bit of work. SAF will solve the same problem as ProviderSignInController (PSIC)--that is, offering sign-in-with-provider functionality. It will do this with tighter integration to Spring Security, as part of Spring Security's filter chain. ProviderSignInController, on the other hand, will work with Spring Security (as it always has), but will be flexible enough to work with security mechanisms other than Spring Security.

Be aware that I have a modified Spring Social Showcase sample that uses SAF instead of ProviderSignInController in a local branch. I'm planning to share that on GitHub soon and hopefully that will clear things up. Since this is still a work in progress, I'm hesitant to push it yet, for fear that it may create more questions than it answers. But know that it should be there sometime soon. I'll follow up on this thread when it's available.

[blandger]

Be aware that I have a modified Spring Social Showcase sample that uses SAF instead of ProviderSignInController in a local branch.

Will examples include 'FB canvas app' (spring-social-canvas) using SAF?

[habuma]

No, the example will not including doing FB canvas app with SAF. That's because neither SAF nor PSIC are really suitable for FB canvas apps. (Yes, I know that the Spring Social Samples canvas example uses PSIC, but I intend to correct that. See https://jira.springsource.org/browse/SOCIALFB-65.)

Both SAF and PSIC go through the typical OAuth 2 flow to obtain an access token. But FB canvas apps don't need to do that. Instead, Facebook will POST to the canvas URL of your application with a signed_request parameter. Encoded in that parameter is the access token. No OAuth 2 authorization flow is required.

What is needed is a simple Spring MVC controller that handles that POST request and uses SignedRequestDecoder to extract the access token. After that it would do pretty much the same as what ProviderSignInController does in its oauth2Callback() method, except that instead of using ConnectSupport to complete the connection by exchanging the code for an access token, it just uses the access token that it was given via the signed_request parameter.

It bears repeating: FB canvas apps use signed_request to give the access token to the app. That is a very different process than what either PSIC or SAF currently support.

I suppose that it's possible to adapt/extend ProviderSignInController (and possibly SocialAuthenticationFilter) to handle the signed_request, but I'm not likely to do that. The signed_request is a FB-only feature for canvas apps, while PSIC and SAF are generic to all providers.

At the moment, however, I'm focusing on the common use case for SAF and not considering how it might play into a FB canvas app.

[blandger]

Thank you for explanation, the difference it is getting more clear.

I also would like to ask your opinion, how do you think about solution for two cases....

Say, I want web-app to be a 'canvas app' with FB integration using offered approach with SignedRequestDecoder.
At the same time app exists as stand alone app and we want users to register/login via FB (or something else) using SAF or PSIC approach.

How do you think, is that possible inside one app ? Of course, it's 'open question' and it 'depends on...'. How do you think if there difficulties are possible integrating two cases in one app?

[habuma]

I foresee no difficulties using the standard canvas app approach alongside SAF or PSIC. In fact, you can use SAF and PSIC together (I have been doing that to some degree in my testing), although it doesn't make much sense in practice to use them together. So long as they don't get in each other's way (e.g., listening on the same endpoint URL), it should be fine.

[blandger]

I wanted to remind you, SignedRequestDecoder has package level visibility only. Hope you'll pull it up for outside package usage.
The same about class SignedRequestException

[blandger]

Craig, could you please post info about configuration parameters from social canvas sample? I mean Facebook config params as canvas url, web site url in FB account.

[habuma]

Yes, I will do that. In fact, I spent some time last night converting the canvas sample to do things the proper way. It's not quite finished, but I'll try to get it out there soon. When I do, I'll also document (somehow...probably with a blog entry) how to configure the app in FB as well as what beans are required in Spring to work with FB canvas.

Be aware, however, that my priority at the moment is to complete the SocialAuthenticationFilter. This significant work needs to be released in a milestone release. I am hoping to finish it up this week, although I have had some distractions that are making that less likely.

Regarding the package scoping of the classes you mentioned, that's largely because (and I had forgotten about this) the @SignedRequest annotation is what you should use to have the access token injected into your controller method. I suppose that there's no reason for those to remain package-scoped, though. The ideal approach is to use @SignedRequest, but there's no reason to keep SignedRequestDecoder private. I'll look into exposing that, too.