A user agent is a browser.
A client is code that runs on the user side, which may or may not be running in a browser. The client uses a browser (user agent) to log in. The idea here is that users should trust the browser with their credentials, while they should not trust their own client code. An example at the end.
A resource owner is a user who allows an application to access resources (data) from their account.
Example. Suppose you have a slideshow application (client) on your ipad that wants to access your Flickr photos. This slideshow app was developed by MysteriousAppDeveloper Inc. If this application asked you (the owner of the resource) to provide your Flickr credentials so that it could access your photos, then you, as a security user, would not do this: you have no idea what this application can do with your credentials . Fortunately, instead of asking for your credentials, instead, it sends your ipad browser (your user agent), which you trust, to sign in to Flickr. You access flickr through your browser, and then the ipad slideshow app requests access to your Flickr photos. You grant access, and then this application can show slide shows of your images (including images with access restrictions), without getting any access to your password. You slept well at night, knowing that the slideshow application does not accept your credentials and does not do something naughty with them.
In my opinion, the Oauth specification is not very motivated. The whole point of the protocol is that users should not trust their credentials to arbitrary applications. Instead, you should limit your trust to applications such as browsers, on which everything depends. The protocol requires users to understand that this is effective.
TheGreatContini
source share