Non-recoverable auth failure?
chowells at janrain.com
Tue Jun 21 11:19:05 PDT 2005
One thing currently absent in the protocol is some form of
non-recoverable authentication failure. The only response for failing
to authenticate that's in the spec is to give the user some chance to
authenticate. But that doesn't seem like it will always be sufficient.
Consider the case of an ID server that locks an account for 24 hours
after three consecutive failed logins. I'm sure everyone is familiar
with that kind of behavior, and can see it as being appropriate in some
cases. When such an ID server has locked an account and someone tries
to log in with that account, the current behavior doesn't quite make
sense. It is effectively telling the consumer "it didn't work, but if
you go here, you might be able to fix it." That's a misleading
statement, as it's just not true. Going to that url won't fix it. This
is a case where it would be clearly better to tell the consumer "that
login is denied."
Having such a message still doesn't reveal any information about why the
login has been denied. It just lets the consumer know that it should
present an error message to the user, rather than trying to get the user
to complete a login sequence that won't be completed.
Also... While looking at the version 0 specs to see the flow for
recoverable auth failure, it seems very strange in checkid_immediate mode.
* auth fails
* send back a response, openid.mode=id_res&openid.user_setup_url=blah.
Well, that feels a bit strange on its own, as id_res seems to be a
heavily overloaded mode. But that's not the point I'm trying to
* consumer pops up a window (or something) going to user_setup_url.
That's where things don't quite make sense. It seems like instead of
having an openid.post_grant argument added, it should instead use
another openid.return_to=url argument. First, it would remove the
current necessity of having the server encode the URL into the
user_setup_url in case the consumer sets openid.post_grant=return.
Second, it covers all the cases just as well. The return_to url can
parent frame that the authentication attempt has concluded so the parent
can then take whatever behavior it sees fit.
Thanks for reading through this. Let me know what you all think.
More information about the yadis