A review of FireEagle's OAuth UI
Published March 18th, 2008 edit replace rm!
FireEagle is Yahoo’s great new location web service which was recently launched into beta.
This review will not cover the API. A great little intro for this can be found in Interfacing a Rails App to Fire Eagle by Kamal.
I have previously written tutorial on writing OAuth Clients in Ruby or Turning your Rails site into an OAuth Provider. So I won’t go over any code here.
This is strictly about the user interface of FireEagle OAuth implementation. The FireEagle team Tom, Seth and Rabble have done an excellent job thinking about the UI and how it affects the security and privacy.
Which is great as most of the rest of us involved in OAuth have been worrying more about standards and implementations than usability. In reality Usability is one of those very important things that the security world tends to forget. So let’s learn from FireEagle’s example.
Registering your application
Firstly you need to make the sale to the application developers. FireEagle does this well. They let us know that FireEagle is nothing without the developer. More important they explain clearly the two main use cases for application developers.
We at Agree2 have a couple of interesting uses for this, so we’ll go ahead and register.
The registration is pretty clear. There are both security details and also information for including your application in their Application Gallery in the future
Of particular note are these settings which are one of the hints that the team have really thought about how OAuth integrates in their application.
Asking the developer what it is they need permission to do, allows FireEagle to ask the correct questions to the user later on.
Finally the application provides all the details to the developer of their consumer keys and secrets. Nothing particularly new here, however they do automatically create an AccessToken for the developer which is a pretty nice innovation that I also recently implemented (stole) into Agree2.
I am assuming that this AccessToken is basically the same as if I went and created an AccessToken manually. Anyone know if this has different rights?
Update Seth from the FireEagle team wrote me to say:
It does indeed have different rights. The access token provided on that page is a “general purpose access token”, which allows clients access to the ‘lookup’, ‘recent’, and ‘within’ methods (and not ‘user’ and ‘update’, as it doesn’t correspond to a user). Conceptually, this token is used for queries done “on behalf of the application” rather than “on behalf of the user”.
Anyway it’s pretty easy to plug this into your application using any number of libraries for just about any language out there.
End user Token Authorization
This is what happens when a Client Application asks a user to authorize them access to their data in FireEagle. A user would be redirected by the Client Application to this screen.
It is great the way it provides a very clear UI explaining the user without too much text exactly what it is they are giving them access to. FireEagle has a really neat way of describing various degrees of precision in sharing your location such as “exact location” or “my current neighborhood”. See below for the full list.
For a simple app like FireEagle it is possible to provide such a concise interface. We are still trying to figure out exactly what we should do in Agree2, as there are lots of potential ways this could be done.
Managing your tokens
Allowing users to manage their tokens is equally important. It provides a list of applications you have issued tokens to. As well as a plain English explanation of the permissions you have given them.
Editing your settings allows you to change permissions for the application.
Privacy in General
While this hasn’t got anything to do with OAuth in itself. Their general privacy settings are also very important. You can really see how the team has thought about Privacy here.
There is a prominent “Hide Me” button, which allows you to instantly “duck” out of site. Think of it like a mute button for FireEagle. This isn’t necessarily useful in all applications, but have a look at your own application if you can’t implement something like this. I assume technically speaking it disables all your AccessTokens until you enable them again.
It is also quick and easy to get rid of your location trail. For an application like FireEagle containing potentially delicate data, this is very important.
Another important aspect is that they automatically implement a timeout functionality. So if you forgot all about FireEagle it will automatically switch off your token’s access at an expiry date unless you specifically renew them.
All in all FireEagle is a great example of implementing OAuth completely into the Application but also on how to think of privacy in a way that I haven’t seen before in web applications.
We’re thinking how we can do just a good job in Agree2. Hopefully the FireEagle team aren’t to upset if we borrow and extend some of the new UI patterns they have come up with.
Todd Sieling March 20th, 2008
Great writeup, and yes indeed FireEagle has done a nice job. One of the nice things about their implementation is that they don’t get into ‘token’ nomenclature with anyone but developers. In designing OAuth experiences, there is a grey zone in exactly what handle we give for end-users for managing authorizations.
When designing thmbnl.com’s oauth features, we went with Authorizations, as code accessing an account might be a full on application, a service, a plugin, a library – there was no single word that seemed to work well.
For most uses, I think ‘Applications’ or ‘Application Access’ is likely the best choice for making the necessary OAuth concepts accessible to end-users who won’t know or care much about what a token is.
Bob April 24th, 2008
You are absolutely right, the level of attention to usability by the Fire Eagle team making this clear for the typical non-tech user is excellent, not one mention of token or OAuth. Great stuff.
Bryce Glass October 20th, 2008
Nice writeup! Very thoughtful. (Also, big ups to Y! designer Samantha Tripodi, who was the design lead for Fire Eagle.)