Description on how the oauth dance works with elgg instances, using the elgg oauth plugin and a test client. The test client will request delegated access into another site, then the original site can use it to access the 2nd site on behalf of the user.
This documents the first test of oauth plugin on lorea, both as a server and a client (each network on one role).
Code for this example is at: http://delcorp.dyne.org/~caedes/testoauth.php
First, the scenario:
We have two networks where an user has an avatar:
The user wants to grant certain privileges on network two to network one, so network one will be able to access network two to execute operations with the permissions delegated by the person. OAuth dance will allow the user to give network one access to network two but being able to control to what extent and not having to give away her identity.
There are several steps to doing this:
0. Generate a request key on network two.
The request key allows an application to make requests for access tokens. Without such a key, a service can't even communicate with our server.
In this example the key has been input into the program code (so it is a test program to access just network 1), so the user doesn't have to do this step.
1. Access the test oauth client on network 1
It is at https://red.artelibredigital.net/mod/testoauth/testoauth.php. Since it is the first time accessing it, we will have no tokens yet. So... click on the "Get token" button.
2. Accept delegating privileges on network 2
We arrive at the "oauth gate" of network 2. Here you have to click on the "Authorize this application" button.
3. Authorization finished.
So we're back to the test oauth client. Now we should see our nickname from the other network, and the shared keys which have been negotiated.
Now server 1 can start using server 2's user data or run actions on server 2 like sending notifications there ;). A relation of trust has been stablished among both networks.
wow, congratulations for all these cool features!
i've added a sentence in the scenario that helps understanding what oauth is about, i hope it's ok... if i've got it, we have to generate requests keys within lorea's seeds (at least the most used ones) and add the links to the test clients somewhere (in the spotlight?) so users can go through steps 1-3, isn't it?
the fact is oauth is a low level protocol with no use for people at the moment :)... so we dont need to add more keys, for now just test exactly the same scenario described on this document.
now, we can build many other federation features on oauth, but thats a next step, for example, OpenMicroBlogging uses oauth, so now we can do OpenMicroBlogging really easy, which means people will be able to federate their microblogging.
about the scenario, i deleted the keys after writing the tutorial! (otherwise everyone knows our secret key!) i just remembered, ill fix the situation so people can test exactly whats written on this document.
i try to explain one more time: with oauth, when you log in one network, you are logged into other networks at the same time -internally- (inverse than with openid, where you can login to many networks, but you are logged into each of them independently). but, because this login is "internal" you can do nothing with it, since it has no interface, you are in network 1 logged into network 2, but network 1 is not prepared to deal with this situation (yet).