Re: [keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter

Hi Bill, actually that's not the way it works - there is no manuall copying of the auth-code needed in the case of desktop apps. An example gist can be found at [1] It works as follows: When a user wants to login via a desktop app (e.g. swing, javafx) a desktop browser is opened window where a user uses the regular keycloak login pages to login. The trick is now that login page is opened with redirect URL that points to a small local "web server" (server-socket) on a free ephemeral port listening on localhost (which should berather 127.0.0.1 according to [0]) which is started by the adapter. After logging in the mini web-server receives the auth code and performs the via the redirect uri: localhost:XXXXX and performs the remaioning authorization code flow. The keycloak-installed adapter eventually receives the tokens (access_token, refresh_token, id_token) which can then be used to call backend services from the client or retrieve new tokens. A nice side effect of this is, that the desktop application never sees a users password and one can leverage existing SSO sessions. Btw. the google cloud cli uses the same approach to authenticate with gcp. [0] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.3 [1] https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb9508 (in the client in Keycloaks needs to allow http://localhost as valid redirect uri - should rather be http://127.0.0.1) Cheers, Thomas 2017-07-20 15:23 GMT+02:00 Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>: What's wrong? The fact you have to cut and paste a code from the browser to the app. On 7/20/17 9:04 AM, Thomas Darimont wrote: > That's interesting. > > Will there also be support for desktop apps in some way? > > What in particular do you think is the problem with the approach > used by the keycloak-installed adapter > and OAuth device flow, guessing you mean: > https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 > <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> ? > > Cheers, > Thomas > > > > 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>>: > > I'm working on something for command line apps. A command-line > text/plain protocol so that login can happen within a > console. I really > think keycloak-installation or the OAuth device flow is > really poor > solution. > > > On 7/18/17 9:42 AM, Thomas Darimont wrote: > > Hello folks, > > > > I played a bit with the undocumented? [0] > keycloak-installed adapter [1] > > for integrating > > desktop applications with Keycloak SSO and found some > issues with it, which > > I'd like to share. > > Small explanation for those who are reading the list but > don't know the > > adapter... [2] > > > > First some general notes / suggestions: > > Is the keycloak-installed adapter something that will stay > in keycloak or > > was this just a PoC? > > In the former case I think there are some things that could > be improved or > > extended a bit: > > > > - Allow users to customize the locale used for the login > pages opened by > > the adapter > > - Provide customizable response templates (perhaps by > leveraging a provided > > ResourceBundle) > > - Allow to customize pages shown after login / logout > served by the > > keycloak-installed adapter > > - Add support for TLS (with custom certificates) for > https:// with localhost > > > > I noticed that some browsers (e.g. Chrome) show an error > page when trying > > to > > redirect to the local mini-webserver after a successful > login since the > > mini-webserver > > (...server-socket) embedded in the adapter doesn't respond > with a valid > > HTTP response. > > With that fixed, it worked with all browsers I tested (IE, > Firefox, Chrome). > > > > My current modifications of the keycloak-installed adapter > > (with HTTP response fixes and response customizations) are > here: > > > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5... > <https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5... > > > > An extended example (using the the modified > keycloak-installed adapter) can > > be found here: > > > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1 > <https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1> > > > > WDYT? > > > > Cheers, > > Thomas > > > > [0] Not mentioned here: > > > https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java... > <https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java... > > > > [1] > https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed > <https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed> > > > > [2] For those that haven't seen the adapter yet, it allows > to authenticate > > against Keycloak > > from a desktop app (e.g. swing, javafx) by opening a > desktop browser window > > where a user > > uses the regular keycloak login pages to login. > > The trick is now that login page is opened with redirect > URL that points to > > a small local > > "web server" (server-socket) on a free ephemeral port which > is started by > > the adapter. > > > > After logging in the mini web-server receives performs the > authenorization > > code flow and eventually receives the tokens (access_token, > refresh_token, > > id_token) which can then be > > used to call backend services from the client or retrieve > new tokens > > > > A nice side effect of this is, that the desktop application > never sees a > > users > > password and one can leverage existing SSO sessions. > > Btw. the google cloud cli uses the same approach to > authenticate with gcp. > > > > The Keycloak repo contains a small example for this: > > > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c... > <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/c... > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > >