From: "Bill Burke" <bburke(a)redhat.com&gt; 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?

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?

Another thing, Android and iOS native apps can redirect to the browser (and vice versa), wouldn't that approach be used in mobile over this?

On 3/6/2014 7:15 AM, Stian Thorgersen wrote: > Support for installed applications in form of two special redirect uris > (urn:ietf:wg:oauth:2.0:oob and http://localhost) has been added. > > There's also a basic example. To try it out start the server as normal, > create an app for it (mark it as public). Download the keycloak.json file. > Then run: > > # mvn -pl examples/demo-template/customer-app-cli install exec:java > -Dexec.args="<path to keycloak.json>" > > You can then run different commands to try it out. It has two different > ways to login the user: > > * login-desktop: this opens a ServerSocket on a local port, opens the login > url in the browser, after login the ServerSocket is used to retrieve the > code > * login-manual: this uses the 'urn:ietf:wg:oauth:2.0:oob' redirect to > display the code in the browser and the user has to manually copy/paste > this into the application > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- 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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; 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&gt; >> 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?

> 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

On 3/7/2014 10:51 AM, Stian Thorgersen wrote: > > 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. > Easy, the hacker doesn't use a browser just a simple script. The client_id of a public client could be known and it just does GET /auth-server/realms/foo/tokens/auth-request?client_id=...&... The server sends a Location response with a localhost uri which contains the query params which contains the code.