 |
 |
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 > >