[keycloak-dev] why authenticate clients?

Stian Thorgersen stian at redhat.com
Mon Mar 3 04:53:22 EST 2014



----- 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 ;)).

> 
> 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
> 


More information about the keycloak-dev mailing list