Re: [keycloak-dev] why authenticate clients?
On 3/10/2014 5:57 AM, Stian Thorgersen wrote:
That's at least one ;)
Confidential clients are always going to be more secure, but public clients are a
requirement so whatever we can do to make them more secure would be great. At some point
confidential clients needs to be exposed to a browser though, and that means they will
need some way of securing the public client. Even a http-only cookie is still vulnerable.
For example if there's an exploit in the browser, or the hacker gains read access to
the file-system, it would be relatively easy to extract the refresh token from the
cookie.
Confidential clients don't need to expose themselves to a browser. Only
the access token needs to be exposed. Confidential clients should
always hold their credentials close and never share them.
That being said, we need to change our pure javascript adapter to be a
public client. Right now any attacker can get access to the client's
credentials by doing a simple GET request, so we should make the
developer aware that our pure Javascript adapter is not confidential by
requiring them to click the "public" option when setting up the application.
I'd also like to have a server-side adapter to support confidential
clients for a pure HTML 5/Javascript application. For example, this
server side adapter would need only one REST endpoint that would only
perform authenticated access token requests.
* Users that don't check the URL (and https certificate)
Even this is mitigated and can be mitigated even more. Currently
everything is digitally signed. Keycloak adapters already verify signed
access tokens. They cold do the same for access codes. Access tokens
are also allowed in Open ID Connect to be encrypted using the client's
secret.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com