Am 03.07.2012 23:41, schrieb Brian Campbell:
That seems clear enough.
Perhaps also saying something along the lines of your last sentence
(saying that including the client_id only protects the client from
substitution of the authorization code) would help address the concern
Justin raised?
+1
I basically support John's proposal but would also propose to explain
the rationale.
regards,
Torsten.
On Mon, Jul 2, 2012 at 4:15 PM, John Bradley <[email protected]> wrote:
Would this be clearer:
ensure the authorization code was issued to the authenticated
confidential client, or to the public client identified by the
'client_id' in the request,
The intent is always that the code must be presented by the client to which
it was issued. That is acceded by authenticating the client in the
confidential case and by inspecting the client_id in the public case.
Yes a client can always fake a client_id in the public case, so it is not
intended to protect the protected resource, only the client from token
substitution.
John B.
On 2012-07-02, at 6:02 PM, Anthony Nadalin wrote:
I read 4.1.3 as the client_id just has to have been issued to a (or any)
public client
From: John Bradley [mailto:[email protected]]
Sent: Monday, July 02, 2012 2:54 PM
To: Anthony Nadalin
Cc: Justin Richer; [email protected]
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3
The change to 4.1.3 requires the endpoint to process it. At least as much
as the the text for the Confidential client is requiring it.
John B.
On 2012-07-02, at 5:45 PM, Anthony Nadalin wrote:
While the client may be forced to provide the client_id there are no
requirements for the endpoint to process the client_id (or how that is done)
so not sure what good the change actually does
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Monday, July 02, 2012 8:32 AM
To: [email protected]
Subject: Re: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3
I'm generally OK with the change, though it does change One problem I have
with this is that it can give a false sense of security about the
information being sent to the token endpoint and how trustworthy it is. A
client_id is public knowledge, and so someone impersonating a client on the
Authentication Endpoint could also impersonate it on the Token Endpoint just
as easily. This is not the attack that's being addressed here, and the
possible phishing vector in the one I'm describing is both well known and, I
believe, well covered by the existing documents. However, I think the new
text might confuse people into conflating these two.
Basically, I think it needs to be made very clear, especially with this
change of text, that a client_id on its own should never be taken as
sufficient for authentication of the client. The context of the user's
decision, among other things, is as important as a client secret.
-- Justin
On 07/02/2012 11:17 AM, Mike Jones wrote:
I believe we should adopt this revised text.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of
John Bradley
Sent: Sunday, July 01, 2012 2:22 PM
To: [email protected] WG
Subject: [OAUTH-WG] New Text for Sec 3.2.1 & 4.1.3
Sec 4.1.2 states:
The authorization code is bound to the client identifier and redirection
URI.
The security concern Sec 10.5 states
If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was
issued to the same client.
Sec 3.2.1
A public client that was not issued a client password MAY use the
"client_id" request parameter to identify itself when sending
requests to the token endpoint (e.g. for the purpose of providing
end-user context, client usage statistics).
Nothing in the current spec requires that a Public client send it's
client_id or redirect_uri to the token endpoint.
The client _id is only sent if it is a confidential client capable of
authenticating itself.
The redirect_uri is only sent if the 'redirect_uri' parameter was included
in the authorization request.
If the client has one registered redirect_uri it would not be sent to the
authorization or token endpoint.
This leaves us with public clients using code flow that cannot determine if
a token was granted to them or some other public client.
I propose changing Sec 3.2.1 to read:
A public client that was not issued a client password MUST use the
"client_id" request parameter to identify itself when sending
requests to the token endpoint. This allows the authorization server
to ensure that the code was issued to the same client.
Sending "client_id" prevents the client from
inadvertently accepting a code intended for a client with a different
"client_id".
Also change Sec 4.1.3 from:
o authenticate the client if client authentication is included and
ensure the authorization code was issued to the authenticated
client,
To:
o authenticate the client if client authentication is included,
o ensure the authorization code was issued to the authenticated
confidential client or to the public client identified by the
'client_id',
The Original text implies that it is a good idea to send it, but is unclear
on what security it provides.
It is a small change that should not brake existing implementations, but
will increase security for public clients using the code flow.
Regards
John B.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
