I'm not sure what use-cases servlet-oauth-client aims to cover and I'm not sure why we have it in the first place. It's not documented nor is it well tested as far as I can tell. On Fri, 8 Mar 2019 at 03:26, 乗松隆志 / NORIMATSU，TAKASHI < takashi.norimatsu.ws(a)hitachi.com&gt; wrote: > Hello, > > I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange) > support for keycloak and merged. > At that time, I had also implemented client side PKCE in servlet oauth > client to demonstrate how PKCE works. > > However, it seemed that I had pushed servlet oauth client codes that did > not work instead of ones used in my local environment. > Therefore, client side PKCE in servlet oauth client does not work. > > I've already known how to fix it, but it is difficult to write Arquillian > integration tests. > > I've searched existing Arquillian integration tests for servlet oauth > client but not found. > > Could anyone help me? > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > _______________________________________________ > 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

On Tue, 12 Mar 2019 at 14:38, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: It is a bit similar to recently deprecated JAXRS filter. AFAIR it is one of the very early-days keycloak features and the use-case behind this was, that you have web frontend java application, which is not secured by Keycloak and doesn't use adapter. But you still want to have a way to invoke the REST services from this application, which are secured by Keycloak. So you want to trigger the OAuth flow manually from the Java without having the adapter to do it for you - that's what this client is doing. I think that this client can be almost always replaced by adapter or by the servlet filter. The only case when it couldn't be replaced by servlet filter is, when you have non-servlet java application. This OAuth client is unmaintained and it is missing lot of features, which were recently added to the adapter. I suggest to deprecate it and then remove in the future (or eventually move to the community maintained extension if people still wants to use it?) +1

Marek On 08/03/2019 08:26, Stian Thorgersen wrote: > I'm not sure what use-cases servlet-oauth-client aims to cover and I'm not > sure why we have it in the first place. It's not documented nor is it well > tested as far as I can tell. > > On Fri, 8 Mar 2019 at 03:26, 乗松隆志 / NORIMATSU，TAKASHI < > takashi.norimatsu.ws(a)hitachi.com <mailto:takashi.norimatsu.ws@hitachi.com>> wrote: > >> Hello, >> >> I had contributed server side PKCE (RFC 7636 Proof Key for Code Exchange) >> support for keycloak and merged. >> At that time, I had also implemented client side PKCE in servlet oauth >> client to demonstrate how PKCE works. >> >> However, it seemed that I had pushed servlet oauth client codes that did >> not work instead of ones used in my local environment. >> Therefore, client side PKCE in servlet oauth client does not work. >> >> I've already known how to fix it, but it is difficult to write Arquillian >> integration tests. >> >> I've searched existing Arquillian integration tests for servlet oauth >> client but not found. >> >> Could anyone help me? >> >> Best regards, >> Takashi Norimatsu >> Hitachi Ltd., >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> 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