[keycloak-dev] Application and server in separate networks
Bill Burke
bburke at redhat.com
Thu Apr 26 08:38:10 EDT 2018
Cool, so POST mode works with Implicit?
On Thu, Apr 26, 2018 at 4:16 AM, Marek Posolda <mposolda at redhat.com> 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/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
>>
>>
>>
>
--
Bill Burke
Red Hat
More information about the keycloak-dev
mailing list