[keycloak-dev] why authenticate clients?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at 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.

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

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

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

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. For example: 

* 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 is.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>