3:53 a.m.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>, 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