I am also getting the same problem with Keycloak :(

I am also getting the same problem with Keycloak :(

Hope to hear from someone who has a solution. Currently my project is stuck and planning to go with a different approach on integrating wordpress with our product. :(

This is something we could look at adding. You could also easily add your own MU Plugin to add say a REST API endpoint for logging out a user. Something like the following: https://gist.github.com/justingreerbbi/768f1effcca69b4098c9d0f7731deba0

Hi, I'm currently evaluating to implement backchannel logout (BCL). We're using Keycloak, which currently (<12.0.0) does not have an OIDC-compatible BCL feature (but it's not far off). Keycloak 12.0.0 implements BCL (https://issues.redhat.com/browse/KEYCLOAK-2940), but we currently can't upgrade.
I'll keep commenting on this thread how I'm going; currently I'm basing my experiments on 3.8.0.
My plan is to provide at least support for Keycloak BCL, from there it's not that far to OIDC BCL.

I cloned the repo and branched it on the 3.8.0 tag: https://github.com/upachler/openid-connect-generic/tree/feature/backchannel-logout

Further tests need to follow, but with fake BCL tokens I could already trigger the logout with this.

What still concerns me is the current lack of token validation in the plugin. I see that so far there was no requirement demanding it, as the ID token is directly issued by the IDP in a response from the token endpoint call - so that alone should already guarantee token validity if you can rule out a man in the middle (which you should be able to with TLS).

However, the OIDC BCL spec demands token validation in Section 2.6:
https://openid.net/specs/openid-connect-backchannel-1_0.html#rfc.section.2.6
This is for a good reason: If the token is not validated, the RP (=Wordpress) is open to DOS in the sense that if an attacker knows a user's subject identifier ('sub' claim), he/she can log the user out.

Because I don't see how to validate the logout token locally without a JWS infrastructure in the plugin, I'm wondering about what to do here.

Options:

• Accept there can be DOS, and make BCL an optional (opt-in) feature, so that only users requiring BCL are risking DOS. The potential damage from such an attack is probably low to medium.
• Mitigate the risk by validating tokens via
  • JWS: The way it's meant to be. Requires fetching public keys from the IDP regularly, and supporting various cryptographic algorithms that IDPs support. Using the public keys tokens can be verified locally. This site gives an overview: https://connect2id.com/blog/how-to-validate-an-openid-connect-id-token. Looks like a lot of effort for such a small feature
  • somehow letting the IDP validate the logout token. The only candidate that comes to mind is the optional token introspection endpoint (https://tools.ietf.org/html/rfc7662). However, this endpoint is designed to introspect OAuth 2.0 tokens, which are effectively access_tokens and refresh_tokens. OAuth 2.0 does not know about BCL tokens. So it is questionable if IDPs would portably support validating BCL tokens. On top of that, the introspection endpoint is optional, so we can't rely on it being there.

Any ideas?

@timnolte @daggerhart, what's your opinion on this?

I like the idea of supporting the JWS mitigation approach. Not sure what it'll take to implement atm, but that seems like the right one to me after reading through this and links.

JWS validation would be the preferred way to go. I'm concerned about the initiation since the WordPress cron is based on site visits and has potential misses. I'm already concerned that we already have a token refresh issue related to this already. If a site admin sets up a server-based cron then it's more reliable, but I'm not sure that every site admin is going to be able to set that up. I'll give this some more review later.

Thanks @timnolte. For now, we'll be accepting the DOS, in terms of threat modelling it won't pose a high risk for us. I'm currently testing in our WP installation, and update this thread when I have news.

@timnolte @daggerhart : I now have a working implementation for my case (Keycloak 4.8) in the head revision of my cloned repo in the feature/backchannel-logout branch (see above). This is still untested for standard OIDC BCL, even though I've implemented a code path for it. I home someone with a compliant implementation can test this.

In order to get the KC 4.8 solution working, the following config steps are needed:

• check the new checkbox in the settings page (look for Keycloak there, you'll find it :)
• save the permalinks page
• set the Admin URL in Keycloak for the client used by Wordpress to / (not sure if this needs to be configurable, for use case that's sufficient)

@upachler if you submit a PR I can install in a Dev environment and test against Azure AD & Google Workspace as I have access to both of those.

Hi, opened the PR as requested. It is created against 'main' as I've based my changes initially against 3.8.0, hope that's ok. If not I can have a look into rebasing them against 'dev'.

@upachler sorry, but you must do your work in a feature branch off of dev. If your work started with main then you will need to start over with a branch from dev.

geez. feared as much. I was able to merge the changes into dev and issued a new PR. The old one is closed.

I'm going to be looking to begin the switch to using the following library to provide the core OIDC functionality, like the Back Channel Logout.

https://packagist.org/packages/jumbojett/openid-connect-php