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

Hello there, So ... looking at your codebase, I assume/guess your strategy is: 1. Find the URLs required from the 2.4.1. Endpoints <http://www.keycloak.org/docs/latest/securing_apps/index.html#endpoints> section of the Keycloak documentation 2. Read the ... http://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint URL as linked from the Keycloak documentation to find the required parameters into each call? Or something else? 3. Synthesize your rest calls to KeyCloak manually? This could work, but ... well ... I feel that these things should really be part of a deliverable within keycloak itself, such as an artifact called keycloak-java-client-3.4.2.Final.jar, with a simple-to-use specification. (In fact, i assumed I was just missing where these deliverables were implemented). Questions regarding a Pure JavaSE Keycloak client implementation Some questions to you folks on the lists, then: 1. A JavaSE client implementation should likely start by fetching the metadata information from /realms/{realm-name}/.well-known/openid-configuration as indicated within the Keycloak documentation. 1. The JaxRS method called to serve the information seems to be getWellKnown within the class RealmResource. True? 2. The object served seems to be OIDCConfigurationRepresentation, rendered as JSON within the response from the service call. True? 3. Hence ... the entity class is OIDCConfigurationRepresentation - and entities which will be needed both at the server side and at the client side (after unmarshaller) could/should be implemented within a separate maven project which can then be included both by the Keycloak Standalone client and the Server. This would serve to minimize the unnecessary dependency bloat on the client side. 2. The JaxRS Client proxy approach, as outlined by the RestEasy documentation <https://docs.jboss.org/resteasy/docs/3.0-beta-3/userguide/html/RESTEasy_C... is a good idea to simplify creating typed and consistent clients. Essentially, if the Server provides an annotated interface for the JaxRS services all that good type information can be used in a simple manner on the client side. 1. Currently, the restful services within the Keycloak codebase do not implement an interface, which implies that the 2 latter lines of code within the code snippet below does not work (the made-up "OpenIdConfiguration" type must be an interface, implemented by the restful service). This is - however - really easy to do; simply extract the typed interface of the RealmResource. I will supply a JIRA ticket for this. 2. Adding a JaxRS 2.x Client filter to auto-inject the Http headers ("Auth: Bearer .. ") into each request to the Keycloak-protected service is simple enough. Perhaps we could/should re-use parts of the code from the Keycloak codebase here. 3. Creating an async timer which polls the refresh-token (i.e. the /realms/{realm-name}/protocol/openid-connect/token endpoint) also seems decently straightforward after getting the token as such. 1. I suggest using the standard ExecutorService and an asynchronously called Task ResteasyClient client = new ResteasyClientBuilder().build(); ResteasyWebTarget target = client.target("http://theKeycloakServer/realms/realmname/.well-known/openid-configuration"); OpenIdConfiguration typedResponse = target.proxy(OpenIdConfiguration.class); typedResponse.getWellKnown("hello world"); Question to you in the list: Is this already available within the Keycloak codebase? If so -- where? 2018-01-04 7:56 GMT+01:00 Hendrik Ebbers <hendrik.ebbers(a)me.com&gt;: -- -- +==============================+ | 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 | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+