Draft 1 OAuth 1.0 spec was announced yesterday. By my count, it requires no less than 6 HTTP request/response round trips assuming the user is already logged in to the service provider.
If the user is NOT logged into the service provider and has to log in before approving or denying the consumer’s request, the number of round trips is increased by a minimum of two for a site using traditional user name/password authentication or even more if the site uses OpenID. Heaven forbid the user isn’t logged into her OpenID provider. In this case the number of request/response round trips skyrockets. Imagine the visible user experience in this case:
- Initiate protected resource request from service provider
- Redirected to service provider’s site to approve request….but wait user is not logged into service provider’s site…
- Prompt for OpenID
- Redirect to OpenID site to verify OpenID…but wait user is not logged into the OpenID provider’s site
- Prompt for OpenID provider’s login credentials
- Prompt to approve service provider’s login request at the OpenID provider site
- Prompt to approve the consumer’s protected resource request at the service provider’s site
- Wait as the service provider redirects back to the consumer with the approved request token….
…which then redirects back to service provider to get the access token…
…which then redirects back to the consumer…
…so that the consumer can redirect back to the service provider and access the intended resource.
This may work great in the bay area where everyone is 10 ms ping time away from everyone else, but try even just a simple OpenID login to a USA-based site when you’re on the Asia-side of the Pacific. Even when you’re already logged in to your OpenID provider, there’s significantly more waiting than the traditional username/password authentication session.
This is an excellent point — and one that admittedly gets obfuscated in the process of developing protocols.
That said, I think that this problem goes away over time as connectivity improves and I also think that the initial time-cost of authenticating in series of steps becomes both regular, easier as interfaces improve, and better yet as we move away from username/password combos being replaced by biometrics or other types of verification.
Additionally, the idea is that as browsers get better at things like OpenID and so on, this whole dance will become a lot easier, just as on the desktop you can limit which apps are allowed to do different things.
All these technologies have a long way to go and it’s important to point out issues like this. At the same time, I don’t think that we should accept that spreading username and passwords all over the place is a good solution either, so until we have something better, this is the best we’ve got for the moment.
You are correct about the first 7 steps but once you get back to the Consumer everything else is done by the Consumer directly so no more redirects. This is still a bit of a hassle the first time you use services from that OpenID/Service Provider combo but unless you are one of those people wearing aluminum hats, your browser cookies are enabled and this gets much better on repeat usage.
There are no magic solutions. If you give your username and password to the Consumer, yes, they do all this for you but can also do anything they want and the only way to stop them is by changing your password (assuming they didn’t beat you to it and hijacked your account). If you don’t, you need a way to give them something you approved.
There are ways to make this better for the user experience but usually at a price of security.
You are due for a new post!!! Get cracken!