One question I’m wrangling with right now is how to add authenticated feeds to an application. I have an application that you have to log into in order to use. The application will publish some feeds. I have to decide whether or not to require authentication to view the feeds, and if so, how that authentication will work.
There are a number of problems associated with feed authentication. The first is that I have no idea what sorts of authentication are widely supported by feed readers. The second is that most people subscribe to many, many feeds, and I wouldn’t want them to have to enter their username and password every time they attempt to refresh the feed. The third is that if you create an authentication system that doesn’t require the user to enter their password, the link to that feed is almost certainly not secure. The user will be able to copy the feed URL and email it to anyone they like. This is especially problematic if the user’s username and password are included in the URL. And the fourth is that regardless which system I use, it needs to be understandable by users who don’t know what RSS, Atom, SSL, and Basic Authentication are.
The good news is that none of the data in this application really demands security. The only reason it’s walled off at all is that it’s going to be published elsewhere later and I don’t want people to start browsing it within the content management system. I could leave out all of the security for the feeds without much worry. If I can bring my support for authentication to the feeds, though, I may as well do so.
I’m looking at how other applications do feed authentication. FogBugz produces RSS feeds and provides two means of authentication. You can consume the feed in an application that maintains your FogBugz cookie (like Firefox), or you can include your username and password as query parameters.
LiveJournal supports authentication for feeds using HTTP Digest for authentication (if you add the right parameter to your URL) or using the LiveJournal authentication cookie if your application has it stored.
37signals’ Basecamp application also uses authenticated feeds. Basecamp’s documentation doesn’t say what form of authentication they use, but a little test reveals that their feeds are authenticated using Basic Authentication.
Daring Fireball also uses Basic Authentication for private feeds.
Needless to say, it doesn’t seem like there’s much standardization in this area, but I think that the best answer is to use Basic Authentication and rely on the user to have a tool that saves their username and password for them if they don’t want to enter it every time. That seems like a preferable approach to creating URLs that have a username and password or even a token included in them. The only problem with that approach is that I have to add support for basic authentication to an application that uses cookies for authentication normally, but at least that’s a problem for the developer rather than a problem for the user.
Feed authentication seems like yet another area where some kind of certificate-based authentication system would be a huge win, but obviously that remains a pipe dream.
June 12, 2006 at 12:58 pm
There is wide support for HTTP Basic Auth (which is secure-ish if you also use SSL) in most clients and libraries. (that said support in some of aggregators requires knowing how to construct an HTTP auth style URL complete with ‘:’ and ‘@’)
Alternately, depending on your your threat model issueing unique URLs per subscriber with 301 redirects makes it simple to invalidate a URL if it gets public essentially creating a shared “secret” key.
June 12, 2006 at 1:08 pm
I had to think about this for a minute. If the data isn’t that important, you could just save the ip of people who have logged into your other app and let those ip’s get to your feed. Otherwise, they probably have to ‘login’ twice. Don’t know if there is any other approach you could reliably get a large portion of feed readers to work with, since, as you pointed out, no one has a widely-supported standard for other thigns.
June 12, 2006 at 5:55 pm
Before I switched to Basic Authentication, I used the “secret key” system for protecting access to Daring Fireball’s members-only feeds. The problem with this, I found, is that too many people use readers like Bloglines where your subscription list is public by default. Anyone who spent 30 seconds googling for one could find a couple of these “secret” URLs.
The only downside to using HTTP Authentication is that some web-based readers still don’t support it, including Google Reader. Most of my members haven’t had any problems with it, though.
June 12, 2006 at 11:01 pm
No reason why you can’t provide more than one authentication mechanism.