[keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter
thomas.darimont at googlemail.com
Thu Jul 20 09:22:55 EDT 2017
some more food for thought:
Google seems to recommend using the Loopback IP address to obtain the
code from a successful Oauth 2.0 interaction in the browser, see .
Create authorization credentials -> Option 2: Loopback IP address (macOS,
Linux, Windows desktop)
Other methods like "manual copy/paste" (of the auth code) or "Programmatic
are supported but not recommended - the recommended approach is to use
Loopback IP address or a Custom URI scheme (on mobile apps or Windows UWP).
Though, one might still be able to programmatically register a custom
in windows and other platforms.
Google also provides some example applications that demonstate the various
Further more, OAuth for Apps: Sample Desktop Application for Windows 
mentions: OAuth 2.0 for Native Apps (draft-ietf-oauth-native-apps-12) 
which descibes the
approaches mentioned above in more detail.
E.g. in 4.1 "Authorization Flow for Native Apps Using the Browser" they
describe the interaction model of the keycloak-installed adapter.
2017-07-20 15:04 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:
> 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 ?
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at 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
>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>> > Hello folks,
>> > I played a bit with the undocumented?  keycloak-installed adapter 
>> > for integrating
>> > desktop applications with Keycloak SSO and found some issues with it,
>> > I'd like to share.
>> > Small explanation for those who are reading the list but don't know the
>> > adapter... 
>> > First some general notes / suggestions:
>> > Is the keycloak-installed adapter something that will stay in keycloak
>> > was this just a PoC?
>> > In the former case I think there are some things that could be improved
>> > 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
>> > 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
>> > I noticed that some browsers (e.g. Chrome) show an error page when
>> > 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,
>> > My current modifications of the keycloak-installed adapter
>> > (with HTTP response fixes and response customizations) are here:
>> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
>> > An extended example (using the the modified keycloak-installed adapter)
>> > be found here:
>> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>> > WDYT?
>> > Cheers,
>> > Thomas
>> >  Not mentioned here:
>> > https://keycloak.gitbooks.io/documentation/securing_apps/top
>> >  https://github.com/keycloak/keycloak/tree/master/adapters/oi
>> >  For those that haven't seen the adapter yet, it allows to
>> > against Keycloak
>> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
>> > 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
>> > the adapter.
>> > After logging in the mini web-server receives performs the
>> > code flow and eventually receives the tokens (access_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
>> > The Keycloak repo contains a small example for this:
>> > https://github.com/keycloak/keycloak/blob/master/examples/de
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
More information about the keycloak-dev