9:51 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 7 March, 2014 3:32:49 PM
Subject: Re: [keycloak-dev] Support for installed applications added (including example)
On 3/7/2014 9:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 7 March, 2014 1:26:50 PM
>> Subject: Re: [keycloak-dev] Support for installed applications added
>> (including example)
>>
>> Couuldn't a lot of the example be pulled into an adapter library and
>> reused?
>
> Yes, that would be good. I mainly wanted to tick the box that we support
> installed applications. With these redirect uris we can claim we support
> CLI, desktop apps, etc..
>
>> Also, is there any security hole you've introduced with being
>> able to cut/paste the access token from the browser? If there is a
>> public client, can a hacker now get an access token?
>
> Don't think so. It's just the code that's available not the token, and
> that's available from the query param in either case. It just displays it
> in the title and page instead.
>
Still sounds like a security hole for public clients. For public
clients we can "validate" that the access *code* is going to a valid
client because of HTTPS. If this "Cordova" support is on by default,
then the hacker can just send a redirect_uri of
"urn:ietf:wg:oauth:2.0:oob" or "http://localhost" and obtain the
access
code. Is "CORDOVA" support on by default currently?
No they are just regular redirect uris. As long as another redirect uri has been specified
for the app they're not valid.
urn:ietf:wg:oauth:2.0:oob is not sent to any clients as its just displayed by the browser
itself.
http://localhost the only difference from what we had before and what we have now is that
if you specify http://localhost as a valid redirect uri, http://localhost:83249 and
http://localhost:34922 will also work.
I don't understand how a hacker would use those redirect uris to obtain a code.
localhost should always point to the local machine, so the code will never leave the
machine. Same with urn:ietf:wg:oauth:2.0:oob in that case the only difference is that the
code is displayed in the title of the page instead of the code query param. If a hacker is
able to intercept the URL of a page in the browser he will be able to obtain the code no
matter what the redirect-uri is.
> BTW this is exactly what Google provides
> (https://developers.google.com/accounts/docs/OAuth2InstalledApp).
>
Google clients require a secret.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com