[keycloak-dev] Authenticating Desktop Applications with Keycloak and the keycloak-installed adapter
Bill Burke
bburke at redhat.com
Thu Jul 20 09:56:44 EDT 2017
Still crap for command line apps where all you have is a console window.
On 7/20/17 9:41 AM, Thomas Darimont wrote:
> 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 at redhat.com
> <mailto:bburke at 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 at redhat.com
>> <mailto: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
>> 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/b8ee52a946e73503b1737f5ca7d4520b8484dae8
>> <https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8>
>> >
>> > 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/java-adapters.html
>> <https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html>
>> >
>> > [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/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java
>> <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java>
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> <mailto:keycloak-dev at 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 at lists.jboss.org
>> <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>
More information about the keycloak-dev
mailing list