[keycloak-dev] why authenticate clients?

[Bill Burke]

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