Re: [keycloak-dev] Application and server in separate networks

We should probably support response_mode parameter [1] and allow "query" mode for implicit invocations. IMO, the HTML POST mode [2] (like SAML does) would be better as with implicit mode, the access token is leaked to browser history. [1] https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [2] http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html On Wed, Apr 25, 2018 at 4:14 PM, Christian Beikov <christian.beikov(a)gmail.com&gt; wrote: > Hey all, > > we reached a point where we are not sure how to proceed with the PR > https://github.com/keycloak/keycloak/pull/5167 for > https://issues.jboss.org/browse/KEYCLOAK-7195 > > We added a client adapter configuration for the flow and that part works > so far, but we noticed that when the Keycloak server encounters a > request for authetication via the implicit flow, it puts the token into > the query fragment part which isn't sent to the application. This is the > point where it becomes obvious this mechanism is intended for the JS > adapter :) > > To resolve the problem and make the flow usable for the Java adapter as > well, we'd need some way to configure the response mode in the > OIDCLoginProtocol. My question is, how you think this should be done. > I was thinking of either allowing a query parameter to specify the > response mode or a configuration switch in the UI for the client. I kind > of prefer the query parameter solution. > > Is this even a change/feature you would be interested in? We need the > implicit flow because the Keycloak server is in a private network that > is separate from the application. Maybe there are other people out there > that have similar needs? > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 20.04.2018 um 09:15 schrieb Niels Bertram: >> Hi Christian, >> >> can't say for sure but the server side adapters always use standard >> authorization flow, which requires your Java app to connect via a back >> channel to (A) exchange code grant for access tokens and (B) to lookup >> jwks for token validation. >> >> The OpenID Connect specification does provide a pure browser based >> flow calledimplicit flow >> <http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth>but >> that one has a few drawbacks such as auth tokens delivered in the >> redirect URL and no refresh token capability. Using this flow could >> solve your problem (A) to shift login flow to the frontend but still >> poses the challenge for (B) validating the tokens at the backend. >> >> I could not find a way to configure the Java adapter to work in pure >> offline validation mode. We had a similar requirement some time ago >> and had to code our own auth module to validate incoming tokens with a >> pre-configured public key. The other common problem we ran into is >> wanting to validate tokens from different (including non-keycloak) >> issuers on the same backend. The Keycloak Java adapters do not support >> this use case either. We originally looked at the Spring JWT adapter >> <https://github.com/spring-projects/spring-security-oauth/tree/master/spri... >> as an alternative but this project is not properly patched and >> configuration is a wonderful garden of mystery like everything in Spring. >> >> Very curious though to see what others are doing. >> >> Cheers, >> Niels >> >> >> On Thu, Apr 19, 2018 at 2:16 AM, Christian Beikov >> <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote: >> >> As far as I see in the code, the Java Adapters always use the >> standard >> flow i.e. response_type=code >> >> Please tell me this observation is wrong and there is an undocumented >> setting I just didn't see that I can use to tell the adapter to >> use the >> implicit flow instead :| >> >> If this is really missing, where would you suggest this should be >> configured? I'd expect the setting to be in KeycloakDeployment and >> OAuthRequestAuthenticator#loginRedirect would then use the value >> instead >> of always using the "code" value. >> >> >> Mit freundlichen Grüßen, >> ------------------------------------------------------------------------ >> *Christian Beikov* >> Am 18.04.2018 um 17:35 schrieb Christian Beikov: >> > >> > Is there any way to avoid the access code to access token exchange? >> > Since the Keycloak server is not accessible, I'm getting an error >> > during authentication: >> > >> > ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default >> > task-54) failed to turn code into token: >> > java.net.UnknownHostException: blabla.local: unknown error >> > ... >> > at >> > >> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:111) >> > at >> > >> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:330) >> > at >> > >> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275) >> > at >> > >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:139) >> > at >> > >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >> > at >> > >> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >> > ... >> > >> > >> > Mit freundlichen Grüßen, >> > >> ------------------------------------------------------------------------ >> > *Christian Beikov* >> > Am 18.04.2018 um 14:48 schrieb Thomas Darimont: >> >> Hello Christian, >> >> >> >> your application server needs to communicate with the Keycloak >> server >> >> to retrieve the realm public key referenced in the token to verify >> >> the token signature. >> >> The current implementation in Keycloak fetches & caches unknown >> >> public keys automatically. >> >> >> >> You could also use a fixed realm public key on the application >> server >> >> side but it would not support key rotation anymore. >> >> >> >> Cheers, >> >> Thomas >> >> >> >> 2018-04-18 13:45 GMT+02:00 Christian Beikov >> >> <christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com> >> <mailto:christian.beikov@gmail.com >> <mailto:christian.beikov@gmail.com>>>: >> >> >> >> Hi, >> >> >> >> is it necessary that an application secured by Keycloak can >> >> access the >> >> Keycloak server? Or is it enough if the Browser can access the >> >> Keycloak >> >> server? >> >> >> >> -- >> >> >> >> Mit freundlichen Grüßen, >> >> >> ------------------------------------------------------------------------ >> >> *Christian Beikov* >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> <mailto:keycloak-dev@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> >> >> <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> >> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev