Contrib.social

Support OIDC standard for communicating locale to/from identity provider

Open on Drupal.org →
Created on 28 July 2023, over 1 year ago
Updated 5 September 2023, about 1 year ago

Problem/Motivation

It seems the OpenID Connect does not support the OIDC standard way of communicating the users locale to the identity provider (IDP).

It appears the module does support `locale` coming back from the IDP.

Do the maintainers feel this kind of functionality is appropriate for this module, or should I pursue a separate plugin instead?

Steps to reproduce

1. Set up a Drupal site with oidc_connect, to support multiple languages
2. User, before logging in chooses a language (e.g. French)
3. User clicks on "Login in with ..." (OIDC provider)
4. User is now at the Identity Provider, in the IDPs default language (e.g. English)

Proposed resolution

The Authentication request should (optionally?) include a `ui_locales` argument that reflects the current language, so that the identity provider can respond to the user in the locale of their preference.

Remaining tasks

  1. Decide if this should be part of openid_connect, or another module/plugin?
  2. If so, decide if the approach used by Keycloak module should be copied?

User interface changes

Admin facing changes. Expose an optional 'Enable multi-language support' checkbox. Possibly also expose (as Keycloak module does) a 'Language mappings' list, to related Drupal language codes to IDP-accepted language codes (spec says RFC5646).

API changes

There are no API changes associated with this issue.

Data model changes

Add these client plugin settings:

  • i18n enabled (boolean)
  • i18n language mapping (sequence/mapping)

Research notes

OIDC spec, at https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

The specification defines the optional ui_locales parameter for "End-User's preferred languages and scripts for the user interface"

The full definition of that parameter is:

OPTIONAL. End-User's preferred languages and scripts for the user interface, represented as a space-separated list of BCP47 RFC5646 language tag values, ordered by preference. For instance, the value "fr-CA fr en" represents a preference for French as spoken in Canada, then French (without a region designation), followed by English (without a region designation). An error SHOULD NOT result if some or all of the requested locales are not supported by the OpenID Provider.

Prior art

Do any of the other openid_connect modules use `ui_locales`?

Keycloak, at https://www.drupal.org/project/keycloak → appears to send `ui_locales`.

https://git.drupalcode.org/search?search=keycloak_locale_param&nav_sourc...

I couldn't find examples in other openid_connect modules.

✨ Feature request
Status

Active

Version

3.0

Component

Code

Created by

🇨🇦Canada leeomara Whitehorse, Yukon

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @leeomara
  • Comment over 1 year ago →
    🇵🇹Portugal jcnventura

    This would be a good feature to have, and if it is part of the standard, even better. Can you propose a patch, please?

    It seems that Keycloak would support this, but maybe you can also tell us another IDP that could be used to test it?

  • Comment over 1 year ago →
    🇨🇦Canada leeomara Whitehorse, Yukon

    I'm currently doing work that's targeting Auth0, but I believe Azure AD also supports ui_locales.

    I'll work on a patch.

  • Comment about 1 year ago →
    🇨🇦Canada leeomara Whitehorse, Yukon

    I've created an initial patch, modifying the OpenIDConnectGenericClient client to support (optionally, when enabled) including a ui_locales arguments in the authorize call to the identity provider. Let me know if this should be made more generic (I.E. parts added to OpenIDConnectClientBase), or if there are other issues with this approach.

    This is a port of the relevant parts from the Keycloak project.

    I've tested this successfully with Auth0, why my English and French (fr) site would send "en" and "fr-CA" to Auth0, based on the site language.

    It's been a long time since I've done serious Drupal work, so any feedback or direction would be much appreciated.

    I was not able to find a relevant place to put in tests (I couldn't see where OpenIDConnectClient plugin functionality was tested), and I'm not proficient enough to know where to start on that front. Again, pointers or corrections are most welcome.

  • Comment about 1 year ago →
    🇨🇦Canada leeomara Whitehorse, Yukon

    Whoops, I accidentally included a logic short-cut that forced isI18nEnabled to always return true. This version has that removed.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024