We’re using the Community Health Toolkit (CHT) with OIDC SSO on shared Android devices and are investigating logout behavior to ensure proper user separation and data protection.
Problem
When User A logs into CHT via SSO and then logs out, the local CHT session ends, but the OIDC Identity Provider (IdP) browser session remains active. As a result, when User B opens the app and selects “Login with SSO”, the IdP can silently (or very quickly) re‑authenticate as User A, so User B inherits User A’s access.
Questions
Does CHT currently support RP‑initiated logout (e.g. calling the IdP end_session_endpoint) when a user logs out of CHT?
If not, are there any recommended configurations or workarounds for shared Android devices to prevent reuse of the previous user’s IdP session?
Can CHT be configured to:
Force re‑authentication on each SSO login (e.g. using prompt=login, max_age=0)
Why this matters
In our deployment, Android devices are routinely shared between health workers. Without a reliable way to ensure that both the CHT session and the IdP session are properly terminated per user, there is a real risk of one user accessing another user’s data or performing actions under the wrong identity.
Any guidance, best practices, or references from other deployments would be greatly appreciated.
The short of it is that we’re going to use work-arounds in the immediate term. Longer term there’s maybe some other options we could think of or add to the CHT
In response to your questions:
Does CHT currently support RP‑initiated logout (e.g. calling the IdP end_session_endpoint) when a user logs out of CHT?
Unfortunately not - the CHT only supports it’s own session cookie being expired which does not affect the OIDC provider’s session. The technical section of the SSO docs cover this as a known limitation (“Back-channel logout is not supported”)
If not, are there any recommended configurations or workarounds for shared Android devices to prevent reuse of the previous user’s IdP session?
The best work around I can think of is to instruct user A to go to the OIDC provider page/app and log out in addition to logging out of the CHT. This will ensure when user B clicks log in, the OIDC provider will force them to login before proceeding.
Additionally, are you still running a shorter default session duration of 8 hours? If this is configured on both the CHT and the Identity Provider, it should offer another level of protection against this scenario.
Can CHT be configured to: Force re‑authentication on each SSO login (e.g. using prompt=login, max_age=0)
The CHT doesn’t offer this configuration either, sorry.
cc @sugat or @jkuester in case there’s anything I’m missing.
One additional thing I would note with regard to back-channel logout and prompt=login/max_age=0, is that these are definitely things that we would consider implementing in the CHT! I am not super familiar with everything that is required to support back-channel logouts, but specifically for the prompt/max_age params, I think it should be simple to support configuring these in the CHT (or maybe using them by default… ). Looking at some docs it does seem like we would also need to validate the auth_time when using those params… This is the kind of thing I always expected we would iteratively add after releasing the MVP of SSO.
@Kenyuri can you confirm if supporting the max_age param would be sufficient for your orgs needs here? If so, maybe I can work up a GitHub issue with some details.
). Looking at