Peter Lacey wrote:
In that I agree. But in my scenario the client of the "authenticate
service" is the resource being accessed, not the client requesting the
resource. Visually:
CLIENT ------ uname/pwd -------> RESOURCE ------ uname/pwd ------->
AUTHENTICATE SERVICE
Right, gotcha. The diagram helps. :)
So, in identity management, you're usually not just wanting to "validate
credentials," but generally want to also return other data, like maybe
the user's full name, email, permissions/authorizations/roles, valid
login times, token & token expiration, last login time, etc.
The request to the AUTHENTICATE SERVICE would generally return at least
some resource that is applicable to your RESOURCE server. But, if there
is absolutely no resource representation that is useful to the RESOURCE
server from the AUTHENTICATE SERVICE, then I think the suggestion to use
HEAD would be appropriate.
I guess the biggest thing I don't like is including any sort of
password, encrypted or not doesn't matter, in the URL. This is just
asking to be recorded somewhere too easily, and then subject to play
back attacks.
I still think that an "authentication service" like you're describing
should use a url scheme like /protected/{username} and use the built-in
HTTP authentication mechanisms. You get the benefits of HTTP caching
and other good things of using this well defined scheme.
Thanks for the conversation. It helps (at least me) to hear what other
people are doing and thinking about.
Adam
