The reason it's failing after upgrading from 1.1 is the check of the redirect uri was added later. This is not a recent regression so we're not going to fix it for 1.8. We can look into it for 1.9 though if you create a JIRA.

My suspicion is that we may not be able to fix it. The problem could be that DeltaSpike is invoked prior to Keycloak adapter, which results in the following behavior:

1. DeltaSpike adds "dswid"

2. Keycloak adapter redirects to login page with redirect uri that includes dswid

3. Keycloak server authenticates users and redirects back to the application (including dswid)

4. DeltaSpike removes "dswid"

5. Keycloak adapter tries to obtain token using redirect_uri param without dswid, which is rejected

Step 5 is a step that we can't remove as it's required by the OpenID Connect specification. It's there to prevent potential attacks.

On 20 January 2016 at 18:17, Christian Beikov <christian.beikov@gmail.com> wrote:

Hello,

we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
1.1.0.Final.
The problem appears when accessing a secured JSF page that uses
DeltaSpike. DeltaSpike redirects the initial request to append a query
param to the path called "dswid". When accesing a secured page, the
Keycloak adapter also does some redirects and adds the redirect uri,
this time the one already including the dswid, into the client session,
but redirects the browser to a URL that includes a redirect uri that
does not contain the dswid. The authentication process fails here:
https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231

Since it worked earlier, I guess this is a bug. The actual problem is
the mismatch between the redirect uri stored in the session and the
redirect uri returned to the browser. Hope you can fix this for 1.8.0.Final

Regards,
Christian
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev