From the perspective of a client, OpenID basically works like this:
- You need to login. You tell the original server what your OpenID URL is, somehow.
- The original server does some redirects, maybe some popups, etc.
- Your OpenID server (attached to your OpenID URL) authenticates you in some fashion, and then tells the original server.
- The original server probably sets a signed cookie so that in subsequent requests you stay logged in. You cannot do this little redirection dance for every request, since it’s actually quite intrusive.
One thought I have is a 401 Unauthorized response, with a header like:
WWW-Authenticate: Cookie location="http://original.server/login.html"
Maybe it would make sense for that location variable to be a URI Template, with some predefined variables, like opener, back, etc.
For general backward compatibility, would it be reasonable to send 307 Temporary Redirect plus WWW-Authenticate, and let XMLHttpRequests or other service clients sort it out, while normal browser requests do the normal login redirect?
Update: Another question/thought: is it okay to send multiple WWW-Authenticate headers, to give the client options for how it wants to do authentication? It seems vaguely okay, according to RFC 2616 14.47.