[keycloak-user] Having difficulty logging out in a 2 client scenario

Stian Thorgersen sthorger at redhat.com
Mon Nov 7 01:12:00 EST 2016

You should have two clients configured. One client for the js app which is
public type (src/main/webapp/keycloak.json) and another one for the
services that are bearer-only (src/main/webapp/WEB-INF/keycloak.json).

On 4 November 2016 at 22:14, Chris Savory <chris.savory at edlogics.com> wrote:

> I have a couple of questions.
>        1. Does it make sense to create a RefreshableKeycloakSecurityContext
> with a null refreshToken?  Seems like this defeats the purpose of that
> object since it is not refreshable in that state.
>        2. I’m looking at SpringSecurityRequestAuthenticator/RequestAuthenticator
> and it looks like an OAuth token is treated differently than a Bearer
> token.  OAuth Tokens are validated back against the keycloak server and
> Bearer tokens are not.  Is there a reason for this?   I thought this would
> be one of the tenants of SSO where I could take a Bearer token and be
> logged in on another client.  But that doesn’t seem possible if that token
> expires and it can’t be refreshed.
>        3. Is it possible for me to:
>        a. extend the Keycloak Spring Security adapter to detect a token
> w/o a refreshToken
>        b. then go to the keycloak server and get one
>        c. save the updated RefreshableKeycloakSecurityContext back to the
> Spring Security Context.
>         4. I’m curious why does SpringSecurityRequestAuthenticator.completeBearerAuthentication
> add the KeycloakAuthenticationToken to the SecurityContextHolder, but the
> SpringSecurityRequestAuthenticator.completeOAuthAuthentication does not?
> The reason I ask is essentially by adding to the holder, it’s going to be
> added to the session by SpringSecurity in Spring’s
> SecurityContextPersistenceFilter, which means that Bearer token will
> persist across requests.  Is that the intention?
> --
> Christopher Savory
> Software Engineer | EdLogics
> On 11/4/16, 1:16 AM, "Chris Savory" <chris.savory at edlogics.com> wrote:
>     Stian,
>     Currently it is both services and a web app.  It’s a monolith in its
> current state.  We have plans to break apart the API services at some
> point, but that is in the future.
>     --
>     Christopher Savory
>     Software Engineer | EdLogics
>     From: Stian Thorgersen <sthorger at redhat.com>
>     Reply-To: "stian at redhat.com" <stian at redhat.com>
>     Date: Friday, November 4, 2016 at 12:18 AM
>     To: Chris Savory <chris.savory at edlogics.com>
>     Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>,
> Danilo Bonilla <danilo.bonilla at edlogics.com>, David Hartfield <
> david.hartfield at edlogics.com>, Ali Elhajj <ali.elhajj at edlogics.com>
>     Subject: Re: [keycloak-user] Having difficulty logging out in a 2
> client scenario
>     Sounds like the Spring Security Adapter is services and not a web app?
> If so it shouldn't deal with logins and logouts at all. It should be
> configured as a bearer-only client.
>     On 1 November 2016 at 00:11, Chris Savory <chris.savory at edlogics.com>
> wrote:
>     Our application has 2 clients:
>     1. A Confidential Client that uses the Spring Security Adapter
>     2. A Public Client that uses the JavaScript Adapter for an Angular SPA
> app.
>     Everything between the two is working fine until I try to logout under
> certain conditions.
>     Logout works fine if I first: deep link into a protected page in my
> app.  The SpringSecurity adapter for client# 1 redirects me to Keycloak.
> Keycloack then logs me in and sends me back to my app where my token was
> issued for client #1.  If I logout under this scenario via the
> SpringSecurity adapter it works fine.
>     In Scenario #2 I first hit an Angular page in my app.  Then I log in
> from the JS Adapter in client #2.  Then through a Rest call to my Spring
> App (which a Bearer token is passed) a java session is established on
> Tomcat.  When I put some break points in the Keycloak Adapter classes I can
> see that the KeycloakToken only contains the token in this scenario, but
> not the refresh token.  I can also see that the token was issued for client
> #2.  When I try to logout, the adapter sends a request to Keycloak with an
> empty refresh_token and keycloak returns a 400 error, thus nullifying the
> logout.
>     I also tried another scenario where use the JS Adapter get the logout
> URL and logout directly to Keycloak via “window.location =
> keycloak.createLogoutUrl({ redirectUri: “/site-url”) }).  This actually
> logs out the user from all clients (which is what I want), but the problem
> here is on the next request to the Spring app I think there is still an
> HttpSession alive and I’m running into the check in
> SpringSecurityTokenStore.saveAccountInfo where it throws an exception
> because there is already an (old) token inside the SecurityContextHolder.
>     Any advice on how to proceed from either of these two scenarios?
>     --
>     Christopher Savory
>     Software Engineer | EdLogics
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/keycloak-user

More information about the keycloak-user mailing list