[keycloak-dev] Application and server in separate networks

Marek Posolda mposolda at redhat.com
Thu Apr 26 04:16:45 EDT 2018 

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/org/keycloak/protocol/oidc/endpoints/AuthorizationEndpoint.java#L227

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 at gmail.com> 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/spring-security-jwt>
>>> 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 at gmail.com <mailto:christian.beikov at 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 at gmail.com <mailto:christian.beikov at gmail.com>
>>>      <mailto:christian.beikov at gmail.com
>>>      <mailto:christian.beikov at 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 at lists.jboss.org
>>>      <mailto:keycloak-dev at lists.jboss.org>
>>>      <mailto:keycloak-dev at lists.jboss.org
>>>      <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

More information about the keycloak-dev mailing list