Authenticating a piece of software isn't how I view the utility of the client
id and secret. It is extremely useful for site to site authentication where a
trust relationship CAN be maintained. We really don't want to lose that
functionality.
________________________________
From: "Manger, James H" <[email protected]>
To: oauth <[email protected]>
Sent: Thursday, April 14, 2011 8:47 PM
Subject: Re: [OAUTH-WG] Revised Section 3
I'm certainly in favour of excluding client auth from OAuth. Dropping section 3
and just having a paragraph like the following would be preferable (with no
capitalized keywords):
In many cases an authorization server will require client
authentication for requests to a token endpoint.
Consequently, a client app that has credentials appropriate
for that server should proactively use them for such requests.
The actual mechanism for client authentication, and any
provisioning of the associated credentials, is outside
the scope of OAuth 2.
I am not a fan of the client_id/client_secret parameters, but was resigned to
their inclusion given existing deployments. Given those parameters are
mentioned, OAuth2 should say:
Various early deployments of the OAuth 2.0 concepts authenticated
clients to the token endpoint using client_id and client_secret
parameters in the request (alongside the grant_type parameter
for instance). A server that accepts client_id/client_secret
parameters MUST also accept the same credentials presented using the
HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request
header).
The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy
(typo?). A server supporting some strong authentication mechanism must not be
mandated to also support weaker BASIC and client_id/client_secret mechanisms --
and certainly not with the same secret!
"3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a
client app swapping an assertion for an access token. Do people want the
additional functionality of using assertions for generic client authentication?
I assumed servers would prefer that clients swap an assertion for a token at
one specific endpoint, then use the token for generic client auth in other
requests -- in which case section 3.3 "Client Assertion Credentials" can be
dropped.
--
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
