Igor,
>> 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).
> Could you
Phil,
> 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
See below..
Phil
phil.h...@oracle.com
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
James,
Could you please clarify the last point (i.e., "cannot look like a
normal authentication protocol")? I simply don't understand what you mean.
With thanks,
Igor
Manger, James H wrote:
Adding client_id here is unnecessary (the server can include it
in the token if it is conveni
Ø 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
The same capability to store the client_id in an opaque value holds true for
the authorization code and refresh token, yet the client_id parameter is
required in those requests. Although section 5.0 does not actually say the
client_id is required in access token requests, but the examples in 5.
From the spec, from section 5, draft 11 obtaining the access token includes
it...
"The client obtains an access token by authenticating with the authorization
server and presenting its access grant (in the form of an authorization code,
resource owner credentials, an assertion, or a refresh tok
You want the client_id on each API request? Put it in the token or
make it part of your API. The token is opaque for a reason.
On Wed, Dec 15, 2010 at 12:22 PM, Paul Walker wrote:
>
> What is the reasoning behind the lack of a client_id parameter in requests to
> protected resources? Could it
What is the reasoning behind the lack of a client_id parameter in requests to
protected resources? Could it not add value if a resource server wanted to
provide IP white-lisitng (in a server to server scenario), in that the resource
server would not have to decrypt/look up the client before de
