Thanks Scott for replying. We don't use an adapter. We have an Angular app that makes HTTP calls to backend services. All of our services are behind a Keycloak Security Proxy. We are migrating away from Oracle OAM to Keycloak, and with Oracle navigating to the logout link was sufficient. I assumed the same would be for Keycloak. I initially thought this might be the bug: https://issues.jboss.org/browse/KEYCLOAK-3311 However, after looking at the logs in Keycloak when I click the Logout button in our app I see the following errors. 18:55:10,630 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-11) RESTEASY002130: Failed to parse request.: javax.ws.rs.core. UriBuilderException: RESTEASY003330: Failed to create URI: null 1. Caused by: javax.ws.rs.core.UriBuilderException: RESTEASY003280: empty host name 2. at org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildString( ResteasyUriBuilder.java:540) 3. at org.jboss.resteasy.specimpl.ResteasyUriBuilder .buildFromValues(ResteasyUriBuilder.java:743) Perhaps it is a combination of the Keycloak Security Proxy and some misconfiguration? I'm not really sure at this moment. Is my assumption correct that we do not need an adapter for oidc logout? On Wed, Sep 21, 2016 at 1:29 PM, Scott Rossillo <srossillo(a)smartling.com&gt; wrote:

Hi folks, I believe the "RESTEASY003330: Failed to create URI" error was due to the non-URL encoded slashes in the redirect_uri. This has since been corrected. The behavior Sean and I are seeing is that accessing the app via a Keycloak Proxy continues to work even after the browser makes a request to the OIDC logout endpoint. The keycloak.<clientId>.session cookie remains in the browser. In the Keycloak admin web UI, the session listed under the user is removed upon request to the logout endpoint. Both Keycloak and the Keycloak Proxy are 2.0.0.Final. Any pointers would be appreciated. Thanks, -John Bartko On Wed, Sep 21, 2016 at 7:01 PM, Sean Schade <sean.schade(a)drillinginfo.com&gt; wrote:

We also have a handful of non-JS and legacy applications which exhibit the same behavior. If a user session is logged out in the KC admin web interface, shouldn't the security proxy stop serving the protected app? I've listed example security proxy and client configs below if that helps any. Security proxy config: { "header-names": { "keycloak-username": "X-UserName" }, "applications": [ { "constraints": [ { "authenticate": true, "pattern": "/" } ], "adapter-config": { "realm": "dev", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4...", "auth-server-url": "https://auth.dev.example.org/auth", "resource": "fooapp.example.org", "public-client": true }, "base-path": "/" } ], "http-port": "8107", "bind-address": "0.0.0.0", "send-access-token": true, "target-url": "http://naked-fooapp.example.org" } Corresponding Keycloak client config: { "webOrigins": [ "http://fooapp.example.org", "https://fooapp.example.org" ], "useTemplateScope": false, "useTemplateMappers": false, "useTemplateConfig": false, "surrogateAuthRequired": false, "standardFlowEnabled": true, "serviceAccountsEnabled": false, "rootUrl": "", "redirectUris": [ "https://fooapp.example.org/*", "http://fooapp.example.org/*" ], "publicClient": true, "enabled": true, "directAccessGrantsEnabled": true, "consentRequired": false, "clientId": "fooapp.example.org", "clientAuthenticatorType": "client-secret", "bearerOnly": false, "baseUrl": "http://fooapp.example.org/", "attributes": { "saml_force_name_id_format": "false", "saml.server.signature": "false", "saml.multivalued.roles": "false", "saml.force.post.binding": "false", "saml.encrypt": "false", "saml.client.signature": "false", "saml.authnstatement": "false", "saml.assertion.signature": "false" }, "frontchannelLogout": false, "fullScopeAllowed": true, "implicitFlowEnabled": false, "nodeReRegistrationTimeout": -1, "notBefore": 0, "protocol": "openid-connect", "protocolMappers": [ { "protocolMapper": "saml-role-list-mapper", "protocol": "saml", "name": "role list", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "protocolMapper": "oidc-usermodel-property-mapper", "protocol": "openid-connect", "name": "given name", "consentText": "${givenName}", "consentRequired": true, "config": { "user.attribute": "firstName", "jsonType.label": "String", "id.token.claim": "true", "claim.name": "given_name", "access.token.claim": "true" } }, { "protocolMapper": "oidc-usermodel-property-mapper", "protocol": "openid-connect", "name": "username", "consentText": "${username}", "consentRequired": true, "config": { "user.attribute": "username", "jsonType.label": "String", "id.token.claim": "true", "claim.name": "preferred_username", "access.token.claim": "true" } }, { "protocolMapper": "oidc-usermodel-property-mapper", "protocol": "openid-connect", "name": "family name", "consentText": "${familyName}", "consentRequired": true, "config": { "user.attribute": "lastName", "jsonType.label": "String", "id.token.claim": "true", "claim.name": "family_name", "access.token.claim": "true" } }, { "protocolMapper": "oidc-usermodel-property-mapper", "protocol": "openid-connect", "name": "email", "consentText": "${email}", "consentRequired": true, "config": { "user.attribute": "email", "jsonType.label": "String", "id.token.claim": "true", "claim.name": "email", "access.token.claim": "true" } }, { "protocolMapper": "oidc-full-name-mapper", "protocol": "openid-connect", "name": "full name", "consentText": "${fullName}", "consentRequired": true, "config": { "id.token.claim": "true", "access.token.claim": "true" } } ] } On Mon, Sep 26, 2016 at 9:53 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: