I’m polishing the OAuth proof of concept implementation in simpleSAMLphp.

Here are some hints about features soon to be ready:

• Permanent Storage for OAuth state (tokens, etc) using Sqlite. Completely automated setup.
• User interface for OAuth Client Registry (see screenshot below).

OAuth is simply ensuring that both parties, requester and responder has the same reference to a user, ‘the current user’, and they both independently may authenticate the user (out of scope of oauth). What is the added value of OAuth here is that it allows you to do backchannel requests regarding a specifc user, ‘the current user’, without using a privacy-invasive identifier. And as a happy coincidence, the OAuth protocol is so simple, it can be implemented in a snap.

Trust model is partly out of scope of the OAuth protocol. Although it has some very useful hooks that allows you to do what you want.

First, it has provider key/secrets, which is a way of managing ‘registered’ consumers, that are allowed to communicate and talk to the oauth provider. You can imagine several ways of handling this:

1. Self-registration of consumers (most common).
2. Self-registration, but with ack from the provider administrator.
3. Provider administrator configures the trusted consumers

When you have a list of consumers, you may setup access control per consumer. In this scenario you could also let the VO admin configure which consumer that are allowed to access what data.

In addition, OAuth gives you the ability to add user consent to release of VO information, and you can also give the user options about what data the consumer may retrieve in that particular session. Including user consent is not straight forward using SAML 2.0 AttributesQueries (backchannel).

To summarize, we may define an apprioriate trust model about registration of consumers and release of VO information - and then OAuth will much likely fit with that model.

• Read more about OAuth on my blog

Last week, I checked in a new module authtwitter in simpleSAMLphp. You can update and use it right away.

It uses the new OAuth authentication API of Twitter that was released April 15th (two weeks ago).

The twitter authentication module re-uses the simpleSAMLphp OAuth module, and add some special functions to get information from Twitter.

I added support for logging in to Foodle through Twitter.

• Test Twitter authentication on Foodle here

What I see more and more, is how difficult it is to make UI for the user to select BOTH where the user comes from AND what kind of authentication method he/she wants to use. The result may be that I extend the SAML 2.0 Discovery protocol even more than I have done already, to allow the UI on the discovery service to include an OpenID field, and as well list some other authentication providers.

I’ve added OAuth support in a module in SimpleSAMLphp and made a proof of concept demo on how to perform authentication initiated from a command line client.

Here is how it looks:

You can update simplesamlphp, enable the oauth module, and run the demo.php command line script your self. The server side is also embedded in the module. Make sure that you do not enable the oauth module on your production server, this is for demo purposes only.

The CLI runs as an OAuth Consumer, the OAuth Service Provider is co-located with a SAML 2.0 Service Provider and perform the federated authentication via an SAML 2.0 IdP.

Here is more or less all the neccessary code that needs to be included in your CLI script:

echo 'Welcome to the OAuth CLI client' . "\n";
$consumer = new sspmod_oauth_Consumer($key, $secret);

// Get the request token
$requestToken = $consumer->getRequestToken($baseurl . 
    '/module.php/oauth/requestToken.php');
echo "Got a request token from the OAuth service provider [" . 
    $requestToken->key . "] with the secret [" . $requestToken->secret . "]\n";

// Authorize the request token
$consumer->getAuthorizeRequest($baseurl . '/module.php/oauth/authorize.php', $requestToken);

// Replace the request token with an access token
$accessToken = $consumer->getAccessToken( $baseurl . '/module.php/oauth/accessToken.php', 
    $requestToken);
echo "Got an access token from the OAuth service provider [" . 
    $accessToken->key . "] with the secret [" . $accessToken->secret . "]\n";

$userdata = $consumer->getUserInfo($baseurl .

Do not use the SimpleOAuthDataStore that is included in the PHP OAuth library. The reason is the obvious relation between the key and the secret. Hash functions are fun to use, isn’t they?

The developer should very well know that md5(md5( is insecure, he/she should use md5(md5(md5( ;P

function new_token($consumer, $type="request") {/*{{{*/
  $key = md5(time());
  $secret = time() + time();
  $token = new OAuthToken($key, md5(md5($secret)));

You may be one of those that have search high and low for the OAuth spec but could not find it. There was a link deep in the mailinglist to an early draft that pointed to a subversion repository, and it worked for a while, but then the link was broken.. Familiar?

Nontheless, the OAuth spec was published few days ago as version 1.0 draft 3.