The task for this week was to add support to the frontend so that desktop clients like osc can add the oauth specific parameters to the http “Authorization” header. The ruby library was already able to handle this and therefore I only needed to do a very small change in our urllib2 OAuthHandler which is used by osc.

Using the Authorization header has one drawback:
– the current flow looks like the following: a client makes an unauthorized API request, the API sends back a 401 to tell the client that it needs to authenticate. Therefore the response also contains the following http header: ‘WWW-Authenticate: basic realm=”Frontend login” ‘. This indicates that the client should use basic auth to authenticate with the API. The question is how we can tell the client that it could also use oauth? Sending back something like ‘WWW-Authenticate: basic, oauth realm=”Frontend login”‘ will probably break some clients. Fortunately darix had a great idea: the client simply tells the server which auth methods it supports. This can be done by adding a new http header like ‘Accept-Authentication: OpenID; OAuth;q=0.8, digest;q=0.7, Basic;q=0.5″ ‘ to each request (q indicates which method is preferred, see other http headers like ‘Accept-Language’ for the details). If the API needs authorization it looks at this header and picks the “preferred” method from this list and sends back ‘WWW-Authenticate: <preferred_and_supported_method>, realm=”Frontend login”‘ ‘. In case the Accept-Authentication header is omitted the application’s default method is used (in our case basic auth). Another thing which needs to be discussed is how the API should behave if the client only accepts methods which aren’t supported by the API (e.g. should the API send back a 401 or 406?).

Apart from thinking about this the other task for this week(end) is to add an UI for managing oauth tokens etc. The first part of this task is to decide which tasks the UI should support (like revoking tokens, authorize tokens etc.).

The next meeting will be on monday to discuss the first results.

The goals for the last week were to implement oauth support into osc and add something like a “ttl” so that an access token expires after some time.

In order to implement it into osc I decided to write a simple OAuthHandler class which can be added as an “opener” to urllib2. So it should be possible to add custom “openers” for other protocols (but the interface might change again).

The next action item was to add a ttl for an access token. In fact this was just a “one-liner” (apart from a small migration script). I’m really impressed how easy it was to do this with rails.

One note about the osc integration:
At the moment osc sends all required authentification stuff (e.g. oauth_token etc.) via url parameters: http://0.0.0.0:3000/source/home:Admin?oauth_consumer_key=<key>&oauth_signature_method=HMAC-SHA1… because we cannot use POST requests. It might be “nicer” to add this kind of parameters to the http header – so our plan is to use the standard http authorization or www-authenticate headers (see also here).

Action item for the next week:

• add support to the frontend so that it can handle oauth via the authorization header.