That is, to take another tack at this that might make it more clear:
The fact that Software Instance A is authorized to do something on
Server B is _not_ baked in at compile time to Software A. That is not
OAuth's security model, in part because it is not a feasible security
model, nobody has yet figured out a way to do that.
Instead, the fact that Software Instance A is authorized to do something
on Server B is, neccesarily, in OAuth's model, determined at run time
with the interaction of a user. Once the user does this interaction,
Software Instance A can keep a security token around that will let it
keep doing that Something on Server B for a Very Long Time, until the
token expires. But that initial authorization requires user interaction
at run-time. That is OAuth's security model.
OAuth's security model does not require each piece of client software to
have a baked-in key of any kind. OAuth does require that there be a
user who has a secret (ie, a login/password) on the foreign server, and
that the user be asked for that secret and enter it (usually directly on
the foreign server, Shibboleth-style) before the first time the software
instance accesses the protected functionality.
Jonathan
Jonathan Rochkind wrote:
MJ Ray wrote:
What is the use case? http://oauth.net/core/1.0a/ claimed "OAuth
creates a freely-implementable and generic methodology for API
authentication." Shouldn't we expect generic authentication to
include authenticating both peers?
OAuth, as I understand it, is about confirming that (eg) Jonathan
Rochkind has given authorization to Software A, to access API services
that read and write to confidential information associated with Jonathan
Rochkind's account on Server B. Server B can be sure that Jonathan
Rochkind authorized Software A to do that. (Or someone that knew
Jonathan Rochkind's secret password did, anyway). And additionally can
let Jonathan Rochkind specify to Server B exactly _which_ services he'd
like to authorize Software A to use, not just all or nothing. Which
happens to be the problem case that ILS api stuff finds itself dealing
with.
I am fairly certain there is _no_ protocol that will allow you to
securely prove that a piece of software on the network is really a
trusted _copy_ of software, when copies of that software are distributed
to untrusted users. It is not a solvable problem. I guess if OAuth
documentation implies they solve it, you can fault them for implying it,
but you can't fault them for not doing it. I am positive you will be
able to find no protocol anywhere that does that. If you need that,
then OAuth will work as well as anything else you can find -- that is,
it won't work, and neither will anything else.
Jonathan
