[keycloak-dev] why authenticate clients?

[Marek Posolda]

On 3.3.2014 10:53, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, 3 March, 2014 9:46:22 AM
>> Subject: Re: [keycloak-dev] why authenticate clients?
>>
>> On 2.3.2014 23:24, Bill Burke wrote:
>>> A good read:
>>>
>>> http://tools.ietf.org/html/rfc6749#section-3.2.1
>>>
>>> I was thinking about our current client-secret requirement.  I don't
>>> think there is any security hole if you are doing the OAuth protocol
>>> over SSL, you are validating redirect_uris and the client sends its
>>> "client_id" when obtaining an access token.
>>>
>>> * Keycloak server ensures the access code is transmitted to a valid site
>>> by verifying/validating the redirect_uri sent.
>> I am not sure if protection based on redirect_uris could be considered
>> secure. For example if Keycloak has application with redirect_uri
>> "http://www.redhat.com/something" then nothing prevents me from adding
>> "www.redhat.com" into my /etc/hosts and run application on my machine
>> bind to "www.redhat.com", which will communicate with Keycloak. It seems
>> that Keycloak won't be able to recognize if request really comes from
>> valid "www.redhat.com" or from my fake host.
> For public clients protecting based on redirect_uri is the only option, as public clients = public secret.
>
> SSL certificates will take care of the example your giving though. If you try to visit https://www.redhat.com and a malicious DNS (or hosts file) swaps that for another site the certificate won't be valid for the domain (unless you've got a compromised certificate authority listed in your browser or use iOS ;)).
yes, protection based on SSL should help. What I mean is that protection 
based just on redirect_uri is not sufficient and can't be considered as 
any real security protection without using anything else (like SSL).

Marek
>
>> Marek
>>> * Since you're using HTTPS, the browser ensures the site is valid by
>>> checking it's cert.
>>> * If you send the "client_id" when obtaining the access token, the auth
>>> server can verify that there was no access code substitution.
>>>
>>> One of the uses described in 3.2.1 is that it is easier to reset a
>>> client's credentials than invalidating all the refresh tokens sent to
>>> it.  I'm not so sure that is true.  If there were a per-app/per-oauth
>>> client Not-Before setting, we could check this on a refresh request.
>>>
>>> Any counter arguments to these assumptions?  I'm going to see if anybody
>>> on the oauth email list will verify these assumptions.
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>