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(a)edlogics.com&gt; 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(a)edlogics.com&gt; 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(a)redhat.com&gt; Reply-To: &quot;stian(a)redhat.com&quot; <stian(a)redhat.com&gt; Date: Friday, November 4, 2016 at 12:18 AM To: Chris Savory <chris.savory(a)edlogics.com&gt; Cc: &quot;keycloak-user(a)lists.jboss.org&quot; <keycloak-user(a)lists.jboss.org&gt;, Danilo Bonilla <danilo.bonilla(a)edlogics.com&gt;, David Hartfield <david.hartfield(a)edlogics.com&gt;, Ali Elhajj <ali.elhajj(a)edlogics.com&gt; 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(a)edlogics.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user