Better Flickr authentication procedure

Enhacement
Today, a new authentication system is released!
Even though the way of authentication was clearly stated everyone that tried failed to use the authentication system. That's a very good proof of a non intuitive system so the authentication modules have been rewritten to work in a more intuitive way. Now the user just have to click a button on his site, answer yes at Flickr.com and that's it!

Technical details
Flickr's login system is limited in that it provides no context when authenticating in the Web mode. Clearly, this is OK for most Flickr applications with a single URL, but since myFlickr authenticates from many different URL:s there's a big problem. MyFlickr now hosts a new server at service.myflick.org which the user gets redirected to after authenticating with Flickr, but since Flickr doesn't provide any hint as to what session the user had with MyFlickr before authenticating, this has to be saved in a cookie in the browser. Since cookies can't be used across domains, the user has to be redirected to service.myflickr.org before being redirected again to Flickr.com. That's many redirects but the user sees only the question on his URL to start the process and the question on Flickr.com to authenticate.

Here's what happens when a user authenticates
The solution is not super elegant but works seamlessly when cookies are enabled, and doesn't require any state at all on the servers. If cookies are disabled, the user has to fill in the server address one extra time.

1. The user visits user.myflickr.org, which presents a start button
2. When the user clicks the start button, user.myflickr.org replies with a redirect to service.myflickr.org/?next=user.myflickr.org
3. The user gets the page at service.myflickr.org which saves user.myflickr.org in a cookie in the browser and redirect to Flickr.com to authenticate with the MyFlickr application
4. The user's browser saves the cookie and goes to Flickr.com where he can decide to authenticate with MyFlickr.
5. If the user accepts MyFlickr to get permission to the user's photos, Flickr redirects the user to a URL which is configured in MyFlickr's API preferences together with a "frob". The Frob is a string that MyFlickr must use to get the user's security token.
6. The User's browser goes to service.myflickr.org. Now with the frob from Flickr in the request URL, and hopefully with a cookie with the address of the album he is trying to authenticate with. (As created in step 3)
7. If the server at service.myflickr.org gets the cookie, it can redirect the user together with the frob to the authenticating server, otherwise the server has to ask the user to fill in a form and provide this information again. This is where Flickr.com has severe limitations in the API. (see below)
8. The user's browser gets redirected back to the domain he tried to claim or authenticate with, together with a frob in the address.
9. When MyFlickr at the proper address gets the user back with the frob, it sends the frob back to flickr and shold get the user's security token back. The security token can finally together with MyFlickr's secret keys be used to access the user's photos.
10. The user configures his site which goes live immediately!

It's a complex procedure with four redirects, but it looks simple to the user. So nothing can possibly go wrong! ;)



Technorati Tags: flickr, authentication, programming