The new Facebook registration service has created quite the "buzz". I have to commend Facebook on doing a great job of making it really simple for sites to manage registrations (just as they did with identity federation). I like the user experience; both for the user and for the integrating site.
However, for relying parties supporting 3rd party identity providers I do have some concerns regarding leveraging the Facebook registration UI for all users.
However, for relying parties supporting 3rd party identity providers I do have some concerns regarding leveraging the Facebook registration UI for all users.
- What happens if the user chooses to clear the form and enters new data? If the site requests password data as part of registration for these users using the "
<code>{"name":"password", "view":"not_prefilled"}</code>" option, when the user comes back to the site, where do they enter their password? How does the site instruct the user that when they come back to the site, they should use the site specific login form, not the Facebook login form? - For users who choose not to register for Facebook, but do want to access the site, where are their login credentials stored? If the site doesn't request password as part of the registration process, is Facebook asking for authentication credentials and storing them (along with which sites the user has logged into)? From working through the documentation, I believe Facebook handles all authentication (even if not storing the registration data) and provides sites with a UID (unique identifier). Effectively, Facebook is a federated identity provider for all users.
- Supporting other federated identity providers becomes confusing. The relying party will have to support two registration forms; one for Facebook users and one for other identity providers. For example, I don't see a way for the relying party to use the Facebook registration UI for a user logging in with their Twitter credentials.
2 comments:
While this is a step in the right direction, I feel that most small businesses would be hindered by the fact that they would most likely need to hire developers to properly implement this. I mean allowing users to register is one thing, but most websites would want it to tie into some kind of database/user management system wouldn't they George?
On a somewhat related note, I am developing a PHP/MySQL based script that allows email marketers to gain user information through a FB Login button. The data is then funnelled into a database and imported into their mailing list on the fly. It currently integrates with Mailchimp and Aweber (which are the heavy hitters in the email mailing list software sector). I basically designed it for email marketers that just want ease of use and don't want to mess around with the Facebook API Documentation. You can learn more about the Beta Program is about to launch: http://fbleadgen.com
I do think that the Facebook Registration Tool will *eventually* become an "out of the box" solution that businesses can get up and running with no programming knowledge, however for now it seems like a lot of small businesses will not be able to utilise it, which is quite unfortunate.
Great`write up. Thanks.
Post a Comment