Hi everyone,
I’m running CHT Core v4.20 in Openshift with Microsoft Azure AD providing OIDC single-sign-on. The default language on both the login page and in system setting is English, and English is listed first in the languages array (Bambara bm and Somali so are also present). When a user lands on the login page everything appears in English, but the moment they authenticate through SSO the interface switches to Bambara. Users can change their profile language back to English, yet the next time they sign out and in, the UI reverts to Bambara again.
Has anyone else observed that the first language in the languages array is ignored when the IdP supplies a locale? Are there best-practice guidelines for ensuring user language choices persist after logout when using external IdPs such as Keycloak, Auth0, or Azure AD?
2 Likes
So, I can confirm that this is expected behavior. When a user does an OIDC login, we will try to initialize the user to the CHT language that matches the value from the locale claim for the user from the OIDC provider. (I know Keycloak allows for the locale to be configured on a per-user basis.) If no locale claim is provided (or there is no CHT language that matches the returned locale), then it should fall back to the first language in the languages entry.
As a brief technical aside, there is no easy way with the OIDC login flow to leverage the locale chosen by the user on the CHT login page. The login page initiates the OIDC login flow, but ultimately it is the OIDC provider page that will send the user back to the CHT once they have successfully authenticated. We provide the redirect_uri that the user should be sent to, but per the spec, we cannot include query params in that URL. Because the OIDC login is a stateless operation from the perspective of the CHT server, we don’t have any easy way to store/track the user’s locale choice from the CHT login page…
This is also expected behavior (and matches the experience of normal (non-SSO) users. The current locale for the user in the CHT app is tracked locally in the client as a cookie and is not preserved between sessions.
The idea when we put together this OIDC locale logic was to use the locale from the OIDC provider as the source of truth for the user’s proper language. It seems like maybe this is not the case? I would be very interested to hear from the real-world cases you are experiencing if there is a more intuitive way we could make this work! 
2 Likes