We are using DHIS2 with SSO (OIDC) and the Android Capture app on shared devices, and we’ve encountered a security concern.
Problem
On shared Android devices:
User A logs into DHIS2 using “Login with SSO Account”.
User A logs out of DHIS2.
The local DHIS2 session ends, but the OIDC IdP browser session remains active.
When User B opens the app and selects “Login with SSO Account”, the IdP can silently (or very quickly) re‑authenticate as User A, so User B inherits User A’s DHIS2 access.
On the web, DHIS2 supports OIDC logout via properties like oidc.provider.{key}.enable_logout and oidc.provider.{key}.end_session_endpoint. However, we have not found documentation showing that the Android Capture app triggers the OIDC end-session endpoint during logout.
Questions:
Does the Android Capture app support OIDC end-session logout?
If not, how are others preventing session inheritance on shared devices?
Are there recommended configurations or workarounds on the IdP or DHIS2 side?
Any guidance or references would be greatly appreciated, as this is important for data protection on shared Android devices.
Thank you for reporting this, and it has been triaged to the @dhis2-android team. For now I would like to mention some important workarounds please: 1. Manual User Logout: Please ask the users when logging out of the DHIS2 App to immediately log out of the browser which they used to sign-in. It might even be better if they could clear the browser app data. Additionally, you could use “Blocking session (PIN)” Android-specific features - DHIS2 Documentation
2. Admin - Configuration changes: If it’s possible, decrease the IdP session timeouts at the OIDC side so that the browser session will expire automatically. Also, if the OIDC supports ‘re-authentication’ it might help so that they will need to authenticate at each request (this will stop User B from sending a request without actually authenticating).
3. Use DHIS2’s standard login: If none of these solutions work, and you’re currently facing this as a security issue then you might want to temporarily disable the SSO and use the standard login method. (until this issue is resolved).
I hope these can provide a temporary adjustment until the issue is addressed. Thank you!