eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

How People Translate Quickly | OpenID Connect Profile Translation QA: Claims Locales Without Changing Identity

—

by

eduKate Asia

Quick answer: localize the profile display, not the account identity

To translate OpenID Connect profile data quickly, distinguish language preferences for the sign-in user interface from language preferences for human-readable claim values, request supported locales when appropriate, and select the returned language-tagged forms without changing the underlying subject identity. In OpenID Connect Core 1.0, ui_locales expresses preferred languages and scripts for the provider’s user interface, while claims_locales expresses preferred languages and scripts for returned claims. A localized family name or profile website label is presentation data; the verified account relation remains anchored by the issuer and subject identifiers, not by a translated name or email address.

OpenID Connect allows language and script variants of suitable human-readable claim values by appending # and a BCP 47 tag to the claim name, such as family_name#ja-Kana-JP and family_name#ja-Hani-JP. Those keys are not decorative. They distinguish alternative human-language forms, and a client needs to select them deliberately, handle absent variants and avoid turning translated fields into account-matching keys. The provider may not support every requested locale, and the request should not be treated as a command to invent names in unsupported scripts.

Begin with an ordinary OIDC security review: identify the provider, the authorized client, the expected UserInfo or claim source, and the exact identity-binding policy. Then identify which values are meant for humans, ask what scripts the user or provider actually supplies, record the requested locale order, and test real provider behavior. The examples in this guide use fictional accounts and deliberately avoid displaying reusable access tokens or authentication secrets. The reader job is narrow: keep multilingual profile claims understandable and safe without changing authorization, user association or consent during language selection.

Understand the split between UI language and claim language

The sign-in page and the profile response are different surfaces

A provider’s sign-in page may appear in Malay while an application’s user profile shows an English name. That is not necessarily a bug. ui_locales is a hint about the provider UI, whereas claims_locales concerns returned claim values; the two can be set independently. An end user can prefer one language for interface controls and another script for their personal name. A good translation workflow records both decisions and avoids assuming that browser language, client locale, user preference and claim language are always identical.

Language-tagged claim names carry the distinction

OpenID Connect uses a # separator within applicable claim names to attach a BCP 47 language and script tag. For example, family_name#ja-Hani-JP can carry a Japanese surname in Kanji, while family_name#ja-Kana-JP can carry a corresponding Katakana representation. These are not interchangeable data merely because they refer to the same person. Preserve the exact claim keys as returned, and do not strip the # suffix before choosing a display form. Treat the untagged field as an independently supplied value under the provider’s rules, not as an English-only guarantee.

The provider may negotiate, approximate or omit a locale

The Core specification treats locale preferences as optional. Providers can return a suitable variation or use an available related language, and lack of support should not ordinarily force an error solely because a requested locale is unavailable. That does not authorize a client to silently mislabel a Chinese or Japanese script or infer spelling from a personal name. Distinguish what the OP returned from what the client chose to display, and record any fallback. Accurate diagnostics must be able to say whether the provider lacked a value or the application ignored an available value.

Claims are not authorization permissions

The presence of profile scope can request default profile claims, but it does not turn a display name into an access control rule. Conversely, claims_locales is not an OAuth scope and should not be placed inside the scope list as if it grants rights. Keep permissions, consent, identity and translation preference as separate parts of the flow. Human-readable explanations of what information will be shared can be localized, but the actual claim request, granted scopes and returned identifiers must remain semantically unchanged and subject to the original security policy.

Only a small pair supplies a stable user key

OpenID Connect Core describes the combination of iss and sub as the guaranteed identifier pair within the stated relationship. Other profile claims—including name, email and preferred username—can change or be reused. A translated surname is particularly unsuitable for login matching because multiple scripts, regional spellings and transliteration conventions can produce several plausible strings. Keep the identity store keyed by verified issuer and subject, and treat translated display fields as attributes that may legitimately vary over time.

Requested locales are ordered language tags

The claims_locales and ui_locales parameters are space-separated preference lists of BCP 47 tags, with the order expressing preference. A UI sometimes sends these parameters as part of an encoded authorization request. Do not separate locale tags with commas merely because a translation spreadsheet uses commas, and do not URL-encode spaces incorrectly when composing a real request. The authorization library should handle encoding; the localization QA should check that the intended tag sequence reached the provider and remained independent from scopes, redirect URI and state handling.

Provider discovery can expose only approximate capability

OpenID Connect Discovery defines optional claims_locales_supported and ui_locales_supported metadata. Those lists can help plan tests, but the specification notes that not every claim necessarily exists in every claimed locale. A provider that supports ja for login screens may not have Japanese name variants for a particular user. Do not interpret capability metadata as permission to fabricate a value or as a guarantee that every account has the same language coverage. Test account-specific responses and document the difference.

Explicit claim requests can need separate feature support

An implementation may optionally support the claims parameter and individual language-tagged claim names. Its discovery metadata can describe that ability, but a client should not assume it is available. A general profile request and a specific request for one family_name#... variant are different operations. If the provider does not honor an optional claim request, fall back according to the application’s legitimate data needs and user expectations. Do not repeatedly broaden consent or request extra personal data only to make a translated profile page look complete.

Language tags and locale identifiers are not human facts

BCP 47 tags such as fr, fr-CA, ja-Kana-JP and zh-Hant identify language or script context; they do not themselves establish nationality, citizenship, ethnicity or a person’s legal name. A provider may return locale as a profile preference, but a relying party should not use it to infer protected or personal characteristics. Translate the interface for clarity while preserving privacy and consent. Ask users to confirm display names and scripts when those forms materially matter instead of generating guesses from national or regional metadata.

Fallback must remain visible and explainable

A robust client can prefer an exact supported variant, then an approved nearby variant or default claim, while recording which key supplied the display. The fallback policy belongs in application code and content design, not in undocumented string replacement. A missing Katakana surname might be better left unshown than automatically transliterated into a misleading form, especially where legal or formal identity is involved. The test suite should include exact-match, partial-match, missing-data and user-overridden display choices.

Treat localization as a distinct security boundary

A translated profile label passes through front-end components, caches, logs and potentially shared UI. Keep its source and language metadata attached to it and apply ordinary output encoding to prevent injection; never treat profile strings as trusted markup. Avoid logging full authentication responses simply to debug missing translations. Record minimally necessary claim keys, locale choices and version information, redacting personal details. A language change should not alter a person’s permissions, authentication state, registered redirect URI or access to another user’s account.

Thirty-two profile cases: locale choices, evidence and safe repair

1. Sign-in language changes but profile remains English

A learner selects Malay on a provider’s login screen, then sees an English family name inside the school app. The login page preference is governed by ui_locales, while the app’s returned claim preferences can be negotiated separately. A product team may wrongly blame the identity provider for an unrelated client display choice.

Inspect both requested parameters, returned claim keys and the application’s selected field before altering any content. Run the flow with independent UI and claims locale values and record the result. Repeat with a provider that supports Malay UI text but has no localized profile names for the account.

2. Claims locale is accidentally sent as a scope

A developer appends claims_locales=ja to the OAuth scope string instead of using its own request parameter. Scopes request authorization categories, not natural-language display preferences, so this syntax has a different function. The provider may reject the scope or ignore the intended language while consent changes unexpectedly.

Move the locale hint into the correctly encoded OIDC parameter and keep approved scopes unchanged. Inspect the authorization request and confirm requested scopes and claim values separately. Test again with a custom scope that has a similar name to prevent accidental parsing confusion.

3. Katakana and Kanji surnames collapse

An application strips language-tag suffixes from both Japanese claim keys and keeps only the last family_name value. The suffix distinguishes script forms that a user may need for different administrative and reader contexts. The profile may show a phonetic name in place of the registered writing or vice versa.

Preserve each returned key and choose the script-aware variant according to explicit requirements. Use a fixture containing both variants and check display and retained raw claims. Repeat where the user prefers Latin transliteration for international email introductions.

4. The account is merged by translated surname

A student system uses the translated family name as its database join key after login. Names are not stable or guaranteed unique across users or issuers, whereas the verified iss/sub pair supplies identity binding. Two students with similar names could be merged, or one student’s record could be split after a script change.

Use the issuer-and-subject pair for account association and keep names as mutable display fields. Create two accounts with the same display name and prove they remain distinct under locale switching. Repeat after one user changes their surname without changing their identity record.

5. Requested locale order is reversed

A client intends to prefer French Canadian over generic French but serializes the list in the opposite order. Locale preference parameters are ordered space-separated language tags, not an unordered set. The provider may choose a less suitable form even when a preferred variant is available.

Preserve the actual user preference order in the request and document how unsupported tags are handled. Inspect the transmitted parameter and compare response variants with the provider’s documented behavior. Test an unsupported first choice followed by a broadly supported second choice.

6. Commas separate locale preferences

A configuration file writes ja-JP, en-US as one value because someone copied a spreadsheet cell. The parameter expects a space-separated list of BCP 47 tags, so comma punctuation may make the request meaningless. The provider may ignore the hint and return an untagged claim without an obvious error.

Serialize locale preferences through the protocol client and assert the decoded sequence matches the intended tags. Use an integration test that captures request parameters before sending an authorization request. Repeat with script subtags and URL encoding to detect whitespace errors.

7. UserInfo returns only an untagged name

The client requests a Japanese display name but the provider returns only an untagged family_name. The protocol permits cases where only one form is returned or a requested variant is not available. It would be misleading to label an unknown-language value as confirmed Japanese.

Apply the documented fallback and allow the user to inspect or amend their display preferences when appropriate. Record requested locales, available keys and selected output, without logging personal values unnecessarily. Test a second account on the same provider that does have tagged names.

8. Provider returns German Swiss variant

A client requests a German name but receives website#de-CH because the provider has no unqualified German value. OpenID Connect allows reasonable provider-side locale matching within the language family. An overly strict client can reject useful data or misreport a protocol violation.

Accept supported related variants under an explicit matching policy while retaining the actual returned tag. Show the selected website and its source key in a QA log, not as a fabricated exact German response. Test a user whose preferred region genuinely changes contractual or privacy language, which needs stricter handling.

Locale negotiation and provider capability

9. Name field becomes an HTML injection route

A relying party inserts a localized nickname directly into HTML because it treats claims as provider-trusted markup. Profile claim strings remain external data and can contain characters meaningful to the rendering system. A malicious or malformed string may change page markup or damage the display.

Apply context-appropriate escaping and render profile values as text, not executable HTML. Test a harmless fixture containing angle brackets, quotes and mixed-script characters. Repeat in email templates and mobile web views, where encoding behavior may differ.

10. Provider capabilities are overpromised

An identity team reads ui_locales_supported as proof that all profile attributes exist in every listed language. Discovery UI support metadata and per-account claim coverage answer different questions. Users are promised localized personal data that the provider cannot actually supply.

Build separate capability and user-data matrices and label unsupported cases accurately. Compare discovery results with real minimal UserInfo responses for test accounts. Test a provider supporting Chinese sign-in screens but only English profile names.

11. Profile data is mistaken for verified identity

A multilingual name claim is presented as proof of a person’s legal identity on a printed certificate. Profile claims can reflect user preferences or provider records and are not equivalent to an independent identity assurance process. A translated display form can be used to make an unsupported legal assertion.

Keep source, assurance and verification status explicit, and do not infer legal validity from local-language display. Compare the application’s claim policy with the actual provider evidence and certificate requirements. Repeat for a name that has changed since the institution issued a credential.

12. Untranslated provider error is confused with profile locale

An authentication error appears in English while claims_locales requests Malay profile data. The authorization server’s error UI and user profile response are distinct surfaces with different localization behavior. The user may assume the account has the wrong preferred language when the issue is an error translation.

Record error response and UI locale hints separately, and localize client-owned error presentation where allowed. Run a failure-path test without changing identity or requested claims. Compare an error shown by the provider with one generated by the relying party.

13. Preferred username is used as stable ID

An internal app saves preferred_username as its user key and later uses a translated variant to find the account. Preferred usernames are neither a universal immutable identifier nor the core guaranteed iss/sub key. Locale or profile updates can break access or route the user to an unrelated local record.

Keep application account mapping tied to verified issuer and subject and treat usernames as display fields. Change the username in a test provider profile while holding iss/sub constant, then verify access remains correct. Test two issuers assigning the same preferred username to different people.

14. Client strips language tags at API boundary

A middleware layer normalizes all keys by splitting at # before passing claims to a front end. In OIDC, # is part of the legitimate language-tagged claim-name syntax, not a comment marker. Two variants can overwrite one another, leaving the front end with a random script form.

Preserve the returned JSON keys and perform language selection after parsing. Use a fixture with two tagged and one untagged family_name field, then compare exact keys end to end. Repeat through analytics or state-management libraries that may reject unusual key characters.

A client sees no Japanese phonetic surname and asks the user to grant wider profile scopes repeatedly. A locale-specific variant may be unavailable even when the provider has other profile data. The user experiences consent fatigue or authorizes more personal information without a clear need.

Separate data availability from authorization scope; request only justified additional claims under provider policy. Compare actual granted scopes and available language variants before and after the retry. Test a provider that does not support individual claim requests.

16. The locale claim is mistaken for citizenship

A service reads locale=zh-Hant and concludes the user has a particular nationality or legal residence. A locale setting describes a language or regional preference, not a verified demographic or citizenship attribute. The application can make inaccurate or discriminatory decisions based on interface preferences.

Use locale only for supported presentation choices and obtain any legally necessary eligibility evidence through approved channels. Review business rules to ensure permissions do not branch on claim language alone. Repeat with multilingual users who switch interface language frequently.

Fallback, security and evidence boundaries

17. Login hint exposes private name in a URL

A developer places a full translated family name into a request URL to work around missing localized claims. Authorization URLs can be copied, logged and observed; personal data should not be added without necessity and consent. Privacy leakage increases while the underlying profile localization problem remains unsolved.

Use supported protocol preferences and legitimate profile APIs, not personal-name query hacks. Inspect sample request URLs and logs for unnecessary personal information. Test a support debugging flow using redacted sample users rather than live accounts.

18. Provider outputs unexpected case in language tag

A provider returns family_name#JA-kana-jp while the client looks only for exact key family_name#ja-Kana-JP. Claim names are case sensitive, but the language-tag values inside them should be interpreted case-insensitively according to the specification. A valid language form may be missed even though its tag expresses the requested variant.

Parse the claim-key suffix explicitly and compare language tags appropriately while preserving original key bytes. Run fixtures with different tag case and confirm equal matching but distinct source provenance. Avoid lowercasing the entire claim key because the base claim name still has case-sensitive semantics.

19. Tag over-specification creates brittle selection

An app insists on fr-CA for a generic French label even when the provider has only fr. Unnecessary language-region specificity can cause avoidable failures in a rigid matching implementation. A supported translation is bypassed and the page falls back to unrelated English text.

Use the least specific tag that captures an actual difference and implement documented fallback where justified. Test exact and generic French variants with a stable requested preference order. Keep a region-specific distinction when it truly affects user comprehension or legal wording.

20. Script is guessed from a person’s email address

A service assumes a user with a .jp domain must want a Kanji claim display. Email routing domain, language preference and name script are independent facts. The app may show an unfamiliar form or mishandle a non-Japanese user in Japan.

Prefer explicit account or user locale preferences and provided language-tagged claims. Test users with international domains and several preferred scripts. Repeat when one person uses a Japanese institutional address and an English professional display name.

21. Response is cached without locale context

A shared profile cache saves a German translated name under a key that contains only the user identifier. When another authorized view requests another language, it can receive the stale display variant. A user may see a mismatched language or, with weak tenant isolation, personal data from the wrong context.

Cache raw authorized claim data safely or include locale and tenant context in the approved derived-display key. Exercise same-user multiple locales and distinct-user access isolation in tests. Repeat across a locale setting change within the same logged-in session.

22. ID token and UserInfo are conflated

A frontend expects every language-specific profile claim to be inside the ID token after successful login. OIDC claim availability depends on response modes, scopes, provider behavior and where claims are returned. A missing value can be wrongly treated as authentication failure or filled from guesses.

Use the provider’s supported claims flow and keep authentication validation separate from optional profile rendering. Inspect sanitized ID token claim names and separately authorized UserInfo responses. Test a provider returning profile names only from UserInfo under the approved access token.

23. Claims parameter is sent to a provider that lacks support

A client builds a fine-grained request for family_name#ja-Kana-JP without checking whether the provider supports the claims parameter. OIDC’s individual claim request facility is optional and can have provider-specific limitations. The request may be ignored or handled differently from the client’s assumptions.

Read provider discovery and integration documentation, then handle unsupported requests without broadening consent. Test with an explicit support flag and inspect the resulting claim set. Repeat against another provider that supports general claims_locales but not fine-grained requests.

A relying party receives a Latin-script name and transliterates it automatically into an invented legal-script spelling. Transliteration choices can be personal or legal and are not guaranteed by OIDC language metadata. The generated name may be inaccurate on identity documents or school records.

Use provider-supplied authorized variants or ask the user for a confirmed display form under policy. Compare the shown name to source evidence without storing unnecessary sensitive documents. Test names with multiple accepted romanization conventions.

Identity stability, user trust and practical support

25. Email address changes after profile update

An application matches returning users by their email claim and treats a newly translated display name as additional confirmation. Email is mutable and not the stable OIDC user identifier pair; names are even less reliable. A legitimate user can lose account access or collide with a former address holder.

Bind accounts to verified issuer and subject, then update display and contact attributes through governed processes. Simulate an email change and prove the mapped account remains stable. Repeat with two providers using an identical email string for different issuer-subject pairs.

A provider returns website#de and website without language tags while another user has only website. The availability of language-tagged variants can vary by user and claim type. Assuming every user has a fixed set of keys creates blank UI fields or false errors.

Select from the actual keys using an explicit fallback, retaining the link target’s provided semantics. Test presence and absence of each variant without changing unrelated claim fields. Ask whether the localized website points to a real translated page rather than just a renamed URL.

27. Language settings alter authorization accidentally

A deployment makes the provider’s locale choice part of an application role lookup. Display preferences are not authenticated role claims and must not change the permissions granted to a user. Switching interface language could alter access, a serious security defect.

Remove language from authorization conditions and rely on approved role and entitlement evidence. Log in under several locale combinations and compare effective permissions to the invariant baseline. Repeat for a user in multiple organizations whose roles differ by tenant, not by language.

28. Long translated name breaks layout but not the account

A Japanese or Arabic name display expands beyond the profile-card width and overlaps a sign-out control. The string can be authentic and protocol-correct while the target interface cannot accommodate its script or length. Users may misread their account identity or be unable to access an important control.

Fix responsive layout, directionality and line wrapping rather than shortening official names arbitrarily. Test real scripts and zoom levels while checking exact returned claim keys. Repeat with combined given and family name fields that produce very long full names.

29. Debug logs contain entire UserInfo responses

To diagnose wrong claim language, a team logs unredacted profile JSON for thousands of users. The problem requires locale metadata and key-selection evidence, not wholesale copies of personal information. Sensitive details can spread into logs outside the intended retention and access policy.

Record redacted claim keys, selected locale and anonymized test IDs under a controlled debugging policy. Check log schema and retention settings with simulated accounts, not production profile dumps. Test whether monitoring agents accidentally copy identity tokens or authorization headers.

30. Account display falls back to a stale nickname

A provider has a current family_name#fr but a client keeps showing an old nickname from a previous profile cache. Local preference and freshness have to be applied to the current authorized claim set. The reader may believe the user’s name was changed back or that the wrong account loaded.

Invalidate derived display caches on relevant profile changes and distinguish nickname from family name. Test profile update propagation alongside locale switching while verifying iss/sub continuity. Repeat with a user who deliberately hides their family name from a public audience.

31. Unsupported locale becomes a false protocol error

A relying party aborts login when the provider cannot return the requested Vietnamese profile name. Claims locale is a preference, and the specification does not generally require authentication failure for unsupported language variants. Users may be locked out solely because their preferred display language is unavailable.

Allow secure authentication to finish, then apply honest, approved profile display fallback behavior. Test unsupported-language login and ensure permissions and identity checks remain unchanged. Repeat when the provider actually returns an authentication error unrelated to localization.

32. Claim value is translated into a different identity

A localization vendor converts a surname by its dictionary meaning rather than preserving the user’s real name. Names and identity attributes are not ordinary descriptive text that translators can freely rewrite. The account view becomes misleading and may harm formal record matching.

Retain source-supplied name forms and use only verified alternate-script values or user-confirmed presentation choices. Check the selected display against provider evidence and an approved user preference. Repeat for branded professional nicknames and compound family names.

Worked example: read two Japanese surname forms safely

A fictional identity provider returns profile claims for the same end user in two Japanese scripts. The application requests Japanese written and phonetic forms but must not generate either from an English spelling. This compact JSON is a sanitized teaching fixture, not a complete OIDC token or proof that a particular provider supports every listed claim. It deliberately includes an issuer and a subject so the display logic can be tested without using a name as the account key. Any real implementation must separately validate authentication responses and obtain claims through the appropriate authorized channel.

{
  "iss": "https://id.example.org",
  "sub": "student-42-b1",
  "family_name": "Yamada",
  "family_name#ja-Hani-JP": "山田",
  "family_name#ja-Kana-JP": "ヤマダ",
  "given_name": "Taro",
  "locale": "ja-JP",
  "email_verified": true
}

The request preference might be claims_locales=ja-Hani-JP ja-Kana-JP en, encoded by the authorization library as required by the request transport. A client with a Japanese Kanji display requirement should choose the ja-Hani-JP field when the value is present, while a phonetic form component may independently prefer the Katakana field. The untagged family_name is available as a fallback but is not guaranteed to be English merely because the example happens to use Latin letters. In tests, retain the exact source key chosen for every rendered value.

Now replace sub with a different identifier while keeping both family names the same. The application must treat that as a different user in the same issuer; identical names do not merge the records. Next keep iss and sub unchanged but remove the Katakana field. Authentication must still succeed under the original security checks, and the phonetic display should follow an approved missing-data policy rather than creating an unverified spelling. This test separates identity validity, claim availability and multilingual presentation in a way that superficial screenshot comparison cannot.

An education organization operates two applications using one OpenID Provider. App A is an English-language timetable; App B offers Japanese and French school-family dashboards. The provider supports French login UI and Japanese script-tagged family names for some accounts, not all. A developer proposes using locale as a school-role selector and generating Katakana names from English family names when missing. Another proposes requesting additional sensitive scopes until every profile has all translations. Design a safer policy for both apps and identify the tests needed before deployment.

Answer: Keep issuer-and-subject identity binding and role/entitlement evidence invariant across apps and locales. Use supported UI preference hints for sign-in surfaces, request appropriately scoped human-readable claims, and choose only available, trustworthy language-tagged values. Do not infer roles from locale, fabricate phonetic names or broaden personal-data consent to satisfy display completeness. Test each provider’s discovery information and actual per-account claim availability, verify both app permissions remain constant under language switches, and document fallback for unsupported scripts. Use redacted fixtures for logs and an explicit user-review path for names requiring confirmation.

The transfer exercise reveals the difference between localization and identity assurance. Translating a button changes how a user understands an action; choosing an official personal name can alter how other people identify them. Both need evidence, but they demand different evidence. By keeping the protocol’s identity anchor stable and making display selection auditable, a team can support multiple school interfaces without silently turning language preferences into security decisions.

Practical review checklist

  • Verify the exact OpenID Connect Core and Discovery profiles supported by the provider.
  • Keep iss and sub identity binding separate from all presentation claims.
  • Distinguish ui_locales, claims_locales, locale, scopes and authorization claims.
  • Preserve preference order and BCP 47 language/script tags during request encoding.
  • Keep exact returned claim names, including any # language suffix.
  • Compare the base claim name case-sensitively and language tags appropriately.
  • Test provider metadata and actual account-specific availability separately.
  • Do not fabricate personal-name translations or phonetic forms from unsupported evidence.
  • Avoid treating email, nickname, language or name as a stable unique key.
  • Escape rendered values and minimize personally identifiable data in logs.
  • Verify authentication and authorization are invariant under locale changes.
  • Test exact, partial, unavailable and mixed-script fallback cases.

Limits and summary

OpenID Connect is an identity protocol, not a multilingual name-generation service. Provider support for a language or optional request parameter does not guarantee that a particular user has verified variants of every claim. A client may need to display a source-script form honestly when no local version is available. It should never claim a translated display value has stronger legal status or identity assurance than the provider evidence establishes. Also remember that optional implementations and client libraries differ, so behavior must be verified against the specific supported Core and Discovery profiles, not assumed from one example response.

A reliable localized profile selects language-tagged human values from authorized claims while preserving account identity, consent and role boundaries. Keep iss and sub stable, distinguish UI language from returned claim language, make fallback explainable and test real provider behavior. The best translation is sometimes the decision not to translate a personal name whose authorized variant is unavailable. That restraint protects the user and keeps a multilingual login experience trustworthy.

Frequently asked questions

What is the difference between claims_locales and ui_locales?

The first is a preferred language and script list for returned human-readable claims; the second is a preferred language and script list for the provider’s user interface. They can produce different results and need not have identical values.

Can claims_locales change the user’s permission scopes?

No. It is a language preference parameter rather than an authorization grant. Keep granted scopes and actual entitlement checks under their own protocol and business rules.

What does family_name#ja-Kana-JP mean?

It is a claim name carrying a BCP 47 suffix for Japanese in Katakana script as used in Japan. It can express a phonetic form distinct from a Japanese Kanji value.

Must the provider always return every requested locale?

No. Locale support and per-user claim availability vary. Missing variants should trigger a documented display fallback, not automatically an authentication failure or invented name.

Is the locale claim proof of nationality?

No. Locale is a presentation preference or profile attribute, not a verified statement of citizenship, residence, ethnicity or entitlement.

Can an email address identify an OIDC user permanently?

Not reliably. OpenID Connect Core identifies the issuer-subject pair as the guaranteed user identifier within the relevant relationship; email and other profile values may change or be reused.

Should I translate a person’s official name automatically?

No. Use provider-supplied authorized variants or a confirmed user preference. Machine-generated transliteration may not match legal or preferred usage.

Why might the login page be French but the profile Japanese?

UI locale and claim locale are separate preferences. A user can prefer one interface language while wanting a different script for their own name.

What if the provider does not support the claims parameter?

Do not assume fine-grained individual-claim requests will work. Check Discovery metadata and integration documentation, then use supported ordinary claim flows and honest fallbacks.

What should be logged when multilingual profile selection fails?

Prefer request locale tags, claim names, source selection decisions and anonymized test identifiers. Avoid retaining unredacted personal names, tokens or full UserInfo responses unless a justified controlled process requires them.

Authoritative sources

Relevant verified internal reading