search

gbv / paia

Specification of Patrons Account Information API (PAIA)
http://gbv.github.io/paia
15 stars 12 forks source link

Login should not send passwords over the wire #42

Closed JonathanRowell closed 9 years ago

JonathanRowell commented 9 years ago

I see that the PAIA Login interface sends the Patron's password to a server which then decides how the login is to be performed. Some people place great faith in HTTPS, but it will only deter the script kiddies. The real question is where does the actual authentication take place? In the client it is the patron who may decide how he wants to login - via Facebook, Google etc, in which case the server MUST accept the credentials required by the service provider. But if this not the case, we ought not to send passwords over the wire, so a challenge/response authentication (MD5 seed) . In fact most people will use their library cards (it may be different for students at a university) and these "patron identifiers" are, I quote, "not recomended" to be used. It is the client who determines what authentication is to be used and not the server.

Incidentally the URL is once again fixed but omits the patron identifier. Why?

nichtich commented 9 years ago

PAIA core can be implemented independent from PAIA auth with any kind of authentication. Valid access tokens could be issued by other means as well. Some tokens may also be valid for multiple patrons.

Rather defining my own challenge-response authentication protocol I'd use an existing specification. Do you have suggestions and use cases?

nichtich commented 9 years ago

Password is only sent on PAIA auth login, everything else is based on temporary tokens. Other authentication protocols can be implemented by providing an alternative to PAIA auth, keeping PAIA core as it is. For instance I'd be happy to include more of OAuth (see https://github.com/gbv/paia/issues/15) but without concrete requirements or use cases for alternatives to PAIA auth, this issue is too broad to be resolved.