----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "Marek Posolda" <mposolda(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Monday, 10 March, 2014 2:33:56 PM
Subject: 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's what I meant. They have to expose the token to the client. Or use some
completely different mechanism to authenticate the client.
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
requiring them to click the "public" option when setting up the application.
Already done, the client_secret is now optional. Not sure if it even needs to be optional
or if we can completely remove it.
I need to write some documentation for the JS lib.
I'd also like to have a server-side adapter to support confidential
server side adapter would need only one REST endpoint that would only
perform authenticated access token requests.
Can you elaborate?
> * 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
Maybe it can be to some extent, but if someone can direct the user to a fake login they
can obtain the users username/password and with that they can do whatever the user can do.
* Get a token directly for a public client
* Get a token indirectly from a confidential client - just auth with the server, and
obtain a token from the cookie instead
Once a users username/password has been compromised there's nothing you can do to stop
an attacker gaining full access to the users account. Except disabling the account that
JBoss, a division of Red Hat