Re: [keycloak-dev] why authenticate clients?

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)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 ;)).

> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >