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

Cool, so POST mode works with Implicit? On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > We support response_mode parameter and we also support HTML POST mode > already on server side. But we specifically disallow "query" response_mode > with implicit flow [1] . This is required per specification and OIDC > certification had a test exactly for this AFAIR. > > [1] > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o... > > Marek > > > On 25/04/18 23:20, Bill Burke wrote: >> 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 >> >>