Using the code flow with a public client in itself creates a false sense of security.
I suspect that most developers think public == implicit and confidential == code. While it is clear that there is a whole group of native apps that are public using the code flow. For those clients the registered redirect URI is the only security. This change adds a bit of protection for the client against an attacker swapping code in the message to gain privilege. I agree that it adds no additional protection for the protected resource. (That is the reason it was not originally included I am guessing) Confidential clients being protected from code being swapped, is mostly a side effect of protecting code from being stolen over non TLS connections. While I do appreciate the problem of making something incrementally safer but not safe, I don't think it is a good idea to leave something vulnerable to a known attack that can be easily fixed. In some ways not fixing this and just saying: OAuth MUST NOT be used as a form of delegated end-user authentication by the client (e.g. third-party sign-in service). The obvious problem with that is that people will just ignore it. John B. On 2012-07-02, at 11:32 AM, Justin Richer wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
