here is a gist that does a manual login by doing a rest call to keycloak. By doing so you
do not need any callback
Next to this you need to handle some other thinks like the refresh of the token on your
own. This must be done in an additional request for example.
Am 04.01.2018 um 03:30 schrieb Lennart Jörelid
So ... I'm unclear about what would be the best way to
1. Use a Native/JavaFX application with its own Login screen and within
its own process. Bring up a browser is not the user experience I would want
to force on the user.
2. Use KeyCloak for authentication
3. After authentication, use KeyCloak to communicate with a
Bearer-token-secured RESTful backend service over HTTP/HTTPS or WebSockets
Is the better way to:
1. Implement a local ServerSocket within the Native/JavaFX application
to accept the KeyCloak Callback. This can be done with something like
Undertow and a tiny handler, so not too complex. However ... I would like a
code example showing how to convert the inbound HttpServletRequest (to the
Undertow server on localhost) from the KeyCloak to the Keycloak
AccessToken. Presumably, one would need to decorate each JaxRS Client call
to the restful webservice (using Bearer token access) with the KeyCloak
Access token as well. Since the JaxRS 2.x Client is the de-facto standard
from the current JavaEE distribution, it would be good to see an example of
how to tailor a ... KeyCloak JaxRS Client request filter, maybe?
I realize, from the example and the codebase, that 99% of the use cases
really nice to have an example holding the scenario above, since it is
basically the way to make native applications or JavaFX clients integrate
properly (i.e. not sprouting a browser, which yields an inferior user
experience) with services protected by KeyCloak. Fair?
2017-07-25 9:52 GMT+02:00 Thomas Darimont <thomas.darimont(a)googlemail.com>:
> Hi Bill,
> that's nice to hear!
> Is there already a JIRA issue for that? May I open a pull request and you
> take it from there?
> I think the TLS feature was a bit over ambitious - so never mind. The idea
> was to optionally allow using
> https for connections to 127.0.0.1 + allowing users to pass-in a custom
> cert / trust store.
> Note that using 127.0.0.1 instead of localhost might cause some
> compatibility problems and should be mentioned in the migration guide.
> E.g. users who already use the keycloak-installed adapter probably need to
> adapt the allowed redirect
> uri pattern in the client configuration in Keycloak (127.0.0.1 instead of
> 2017-07-25 0:21 GMT+02:00 Bill Burke <bburke(a)redhat.com>:
>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>>> - Add support for TLS (with custom certificates) for https:// with
>> Hey, I'm incorporating your changes, but one question I have is why do
>> you need this?
>> keycloak-dev mailing list
> keycloak-dev mailing list
| Bästa hälsningar,
| [sw. "Best regards"]
| Lennart Jörelid
| EAI Architect & Integrator
| jGuru Europe AB
| Mölnlycke - Kista
| Email: lj(a)jguru.se
| URL: www.jguru.se
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
keycloak-dev mailing list