4:24 p.m.
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.
* 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:25 p.m.
Ugh sorry, rephrase:
"I don't think there is a need for authenticated clients if you're
doing..."
On 3/2/2014 5:24 PM, 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.
* 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:33 a.m.
Not sure what you're proposing. Are you saying that we shouldn't authenticate
clients at all?
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Sunday, 2 March, 2014 10:25:21 PM
Subject: Re: [keycloak-dev] why authenticate clients?
Ugh sorry, rephrase:
"I don't think there is a need for authenticated clients if you're
doing..."
On 3/2/2014 5:24 PM, 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.
> * 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.
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:52 a.m.
On 3/3/2014 4:33 AM, Stian Thorgersen wrote:
Not sure what you're proposing. Are you saying that we
shouldn't authenticate clients at all?
Not proposing anything. Our pure-javascript/html5 adapter is a public
client. I'm just saying that in that case, its just as secure as a
confidential client is you use SSL. It also helps in cases where its
difficult to distribute/store client secrets, i.e. in the multi-tenant
case that Travis (a keycloak user) has been talking about on the user list.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:46 a.m.
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.
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.
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
4:14 a.m.
On 3.3.2014 10:53, Stian Thorgersen wrote:
----- 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 ;)).
yes, protection based
on SSL should help. What I mean is that protection
based just on redirect_uri is not sufficient and can't be considered as
any real security protection without using anything else (like SSL).
Marek
> 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
>
11:58 a.m.
Okay, I think I've figured out why confidential clients are better.
Hacker could spoof the login page, obtain client credentials, in the
background have a script that performs the login flow. With a public
client, the hacker would be able to get the access token as there is no
protection. With a confidential client, the hacker would not have the
client credentials and would not be able to turn a code into a token.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:57 a.m.
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.
End of the day there's a few things that are outside of our control:
* Exploits in browsers
* Hackers that gain access to file-system
* Users that don't check the URL (and https certificate)
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Marek Posolda" <mposolda(a)redhat.com>, "Stian Thorgersen"
<stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 7 March, 2014 5:58:23 PM
Subject: Re: [keycloak-dev] why authenticate clients?
Okay, I think I've figured out why confidential clients are better.
Hacker could spoof the login page, obtain client credentials, in the
background have a script that performs the login flow. With a public
client, the hacker would be able to get the access token as there is no
protection. With a confidential client, the hacker would not have the
client credentials and would not be able to turn a code into a token.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:33 a.m.
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
9:44 a.m.
----- 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.
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
3926
days inactive
3934
days old
10 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen