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 https://lists.jboss.org/mailman/listinfo/keycloak-dev

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>>: 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> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

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.AbstractUndertowKeycloakAuthMe ch.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>>: >> >> 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> >> 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

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

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 > > >

I think it works, but didn't tested that combination. And POST is not supported by any of our adapters ATM, just by server. I know that some of our users use Form POST with 3rd party adapters, but likely the combination of FormPOST with standard flow. On 26/04/18 14:38, Bill Burke wrote: > 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 >>> >>> > >

SAML would definitely work for your case so long as you don't need a token to make other REST invocations.

I can't get SAML to work. Everytime I try to access a protected page, I get the error "Client is not allowed to initiate browser login with given response_type. Standard flow is disabled for the client". In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null, userId=null, ipAddress=10.0.0.1, error=not_allowed" Is there anything I can do to further debug this? I'm using 3.3.0.Final and configured SAML via keycloak-saml.xml having roughly the following content <?xml version="1.0" encoding="UTF-8"?> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:keycloak:saml:adapter http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd"> <SP entityID="myapp" sslPolicy="EXTERNAL" nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" logoutPage="/logout" forceAuthentication="false" isPassive="false" turnOffChangeSessionIdOnLogin="false"> <IDP entityID="idp" signaturesRequired="false"> <SingleSignOnService requestBinding="POST" bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" /> <SingleLogoutService requestBinding="POST" responseBinding="POST" postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" /> </IDP> </SP> </keycloak-saml-adapter> Am I missing something or is having a SAML endpoint on Keycloak along with a SAML client not a supported scenario configuration? Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 26.04.2018 um 16:50 schrieb Bill Burke: > SAML would definitely work for your case so long as you don't need a > token to make other REST invocations. > > On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov > <christian.beikov(a)gmail.com&gt; wrote: >> Thanks for the hints. I'll try to see if I can get SAML to work and let >> you know of the result. Anyway, the POST response_mode sounds promising >> and would definitely work in our case. When I put the URL hash I got >> while testing into the query part of the URL, the authentication worked >> properly. So doing a form encoded POST would probably work as well. >> >> >> Mit freundlichen Grüßen, >> ------------------------------------------------------------------------ >> *Christian Beikov* >> Am 26.04.2018 um 15:06 schrieb Marek Posolda: >>> I think it works, but didn't tested that combination. And POST is not >>> supported by any of our adapters ATM, just by server. I know that some >>> of our users use Form POST with 3rd party adapters, but likely the >>> combination of FormPOST with standard flow. >>> >>> On 26/04/18 14:38, Bill Burke wrote: >>>> 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 >>>>>> >>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> 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

Also make sure that your client id matches the one configured for the client in the admin console. That might be the problem too. On Sat, Apr 28, 2018 at 12:32 PM, Bill Burke <bburke(a)redhat.com&gt; wrote: > Enable standard flow for the client. Its a switch in admin console > client config. > > On Sat, Apr 28, 2018 at 11:11 AM, Christian Beikov > <christian.beikov(a)gmail.com&gt; wrote: >> I can't get SAML to work. Everytime I try to access a protected page, I >> get the error "Client is not allowed to initiate browser login with >> given response_type. Standard flow is disabled for the client". >> >> In the logs I see "type=LOGIN_ERROR, realmId=LOCAL, clientId=null, >> userId=null, ipAddress=10.0.0.1, error=not_allowed" >> >> Is there anything I can do to further debug this? I'm using 3.3.0.Final >> and configured SAML via keycloak-saml.xml having roughly the following >> content >> >> <?xml version="1.0" encoding="UTF-8"?> >> <keycloak-saml-adapter xmlns="urn:keycloak:saml:adapter" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="urn:keycloak:saml:adapter >> http://www.keycloak.org/schema/keycloak_saml_adapter_1_7.xsd"> >> <SP entityID="myapp" >> sslPolicy="EXTERNAL" >> nameIDPolicyFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" >> logoutPage="/logout" >> forceAuthentication="false" >> isPassive="false" >> turnOffChangeSessionIdOnLogin="false"> >> <IDP entityID="idp" >> signaturesRequired="false"> >> <SingleSignOnService requestBinding="POST" >> bindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" >> /> >> >> <SingleLogoutService >> requestBinding="POST" >> responseBinding="POST" >> postBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" >> redirectBindingUrl="http://auth.company.com:8081/auth/realms/LOCAL/protocol/saml" >> /> >> </IDP> >> </SP> >> </keycloak-saml-adapter> >> >> Am I missing something or is having a SAML endpoint on Keycloak along >> with a SAML client not a supported scenario configuration? >> >> Mit freundlichen Grüßen, >> ------------------------------------------------------------------------ >> *Christian Beikov* >> Am 26.04.2018 um 16:50 schrieb Bill Burke: >>> SAML would definitely work for your case so long as you don't need a >>> token to make other REST invocations. >>> >>> On Thu, Apr 26, 2018 at 9:59 AM, Christian Beikov >>> <christian.beikov(a)gmail.com&gt; wrote: >>>> Thanks for the hints. I'll try to see if I can get SAML to work and let >>>> you know of the result. Anyway, the POST response_mode sounds promising >>>> and would definitely work in our case. When I put the URL hash I got >>>> while testing into the query part of the URL, the authentication worked >>>> properly. So doing a form encoded POST would probably work as well. >>>> >>>> >>>> Mit freundlichen Grüßen, >>>> ------------------------------------------------------------------------ >>>> *Christian Beikov* >>>> Am 26.04.2018 um 15:06 schrieb Marek Posolda: >>>>> I think it works, but didn't tested that combination. And POST is not >>>>> supported by any of our adapters ATM, just by server. I know that some >>>>> of our users use Form POST with 3rd party adapters, but likely the >>>>> combination of FormPOST with standard flow. >>>>> >>>>> On 26/04/18 14:38, Bill Burke wrote: >>>>>> 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 >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> 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 > > > -- > Bill Burke > Red Hat

That doesn't work either. Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 29.04.2018 um 20:53 schrieb Ramunas: > Try configure without asterix - "http://localhost:8080/". _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev