See below.. Phil [email protected]
On 2010-12-15, at 4:09 PM, Manger, James H wrote: > Ø What is the reasoning behind the lack of a client_id parameter in requests > to protected resources? > > When the client app is acting on its own behalf (with the app’s own long-term > credentials)… the client_id is included as part of authenticating the client > app (as a query/form parameter, or as the user-id field in a “Authorization: > BASIC” header, or in any other authentication mechanism). > > When the client app is acting on behalf of a user (with credentials from an > OAuth token response)… the client_id is NOT included. The credentials from > the token response are sufficient. Adding client_id here is unnecessary (the > server can include it in the token if it is convenient for protected > resources), and harmful (it means the protocol that uses the credentials from > the token response cannot look like a normal authentication protocol). It is useful for the resource authorization policy server to know what client is acting on behalf of what user. E.g. if a financial aggregator was using OAuth to access a bank, the bank systems can differentiate rights between normal end-user access and a client app access (e.g. read-only regardless of scope). I know scope already covers some of this, but it seems like an important distinction if for some reason a policy server needs to apply additional rules for clients beyond those of scope. > > -- > James Manger > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
