Client Side OpenID
The following article discusses ideas that I wouldn't even class as vapourware, as I am not proposing to implement them myself. That said, the ideas should still be implementable if anyone is interested. One well known security weakness in OpenID is its weakness to phishing attacks. An OpenID authentication request is initiated by the user entering their identifier into the Relying Party, which then hands control to the user's OpenID Provider through an HTTP redirect or form post. A malicious RP may instead forward the user to a site that looks like the user's OP and record any information they enter. As the user provided their identifier, the RP knows exactly what site to forge. Out Of Band Authorisation One way around this is for the OP to authenticate the user and get authorisation out of band — just because the authentication message begins and ends with HTTP requests does not mean that the actual authentication/authorisation need be done through the web browser. Possibilities include performing the authorisation via a Jabber message or SMS, or some special purpose protocol. Once authorisation is granted, the OP would need to send the OpenID response. Two ways for the web browser to detect this would be polling via AJAX, or using a server-push technique like Comet. Using a Browser Extension While the above method adds security it takes the user outside of their web browser, which could be disconcerting. We should be able to provide an improved user experience by using a web browser extension. So what is the best way for the extension to know when to do its thing? One answer is whenever the user visits the server URL of their OP. Reading through the specification there are no other times when the user is required to visit that URL. So if the web browser extension can intercept GET and POST requests to a particular URL, it should be able to reliably detect when an authentication request is being initiated. At this point, the extension can take over up to the point where it redirects the user back to the RP. It will need to communicate with the OP in some way to get the response signed, but we have the option of using some previously established back channel. Moving the OP Client Side Using the browser extension from the previous section as a starting point, we've moved some of the processing to the client side. We might now ask how much work can be moved to the client, and how much work needs to remain on the server? From the specification, there are three points at which the RP needs to make a direct connection to the OP (or a related server): When performing discover, the RP needs to be able to read an HTML or XRDS file off some server. The associate request, used to generate an association that lets the RP verify authentication responses. The check_authentication request, used to verify a response in the case where an association…