- MicroblogPoster Free
- MicroblogPoster Add-ons
- Customers Area
- MicroblogPoster Support
- MicroblogPoster Help
How do social sites’ APIs control access to protected resources?
In the case of Microblogposter the ‘protected resource’ is the write access to your profile/page/group. When MicroblogPoster makes a request to publish on your behalf the social site’s API needs to know that the request was ‘allowed’ by you (the User).
When you’re logged in on a social site you have access to your resources and you have write access to your profile timeline. While using the API the social site needs to somehow authenticates MicroblogPoster and control the access. We’re going to enumerate different methods APIs are using to check the ‘right to write’ to the timeline/wall/group discussion.
There are 4 different methods of doing, at least based on sites we’re supporting.
Used by: Facebook, Linkedin, VKontakte, Blogger, Bitly, Googl
The OAuth 2.0 Authorization Framework (http://tools.ietf.org/html/rfc6749)
Introducing OAuth 2.0 (http://hueniverse.com/2010/05/15/introducing-oauth-2-0/)
Roles in the use case of MicroblogPoster:
- resource owner (you, the User)
- client (you, actually the Application you create, ie. App)
- resource server (social site, ie. facebook, twitter)
This is the famous “authorization of the account”, once you saved it. You’re asked to login to the social site and to allow/grant the App posting on your behalf. The App gets an access token and then can auto post to your wall/timeline, without using your username/password. The bottom line being that you’re not storing your username/password in wordpress db but however, MicroblogPoster via your App can post to social sites.
Used by: Twitter, Plurk, Tumblr
The OAuth 1.0 Protocol (http://tools.ietf.org/html/rfc5849)
Pretty much the same as the version 2 when it comes to the goal to achieve, ie. being able to access protected resources without classical username/password authentication.
In the version 1 of OAuth, 2 steps are required instead of 1 in order to authorize the social account. We can say that the version 2 was simplified on that point.
API Key :
Used by: FriendFeed, Diigo
The social site require a special ‘password’ (ie. Api key) when accessing its resources via API.
Username + password :
Used by: Delicious, Instapaper, Diigo
You can access the API with username/password combination. Diigo implemented a mix with additionally the API key, so they are requiring username/password/api key.
We’ve briefly outlined why for some social sites you need to create an App and why for others the combination username/password suffice. It depends on the social network.