[keycloak-dev] Application and server in separate networks
Bill Burke
bburke at redhat.com
Wed Apr 25 17:20:43 EDT 2018
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
--
Bill Burke
Red Hat
More information about the keycloak-dev
mailing list