Allow usernames containing non-ASCII Unicode characters through an opt-in setting.

Feature Description

The current ASCII-only restriction prevents users from using their actual names or preferred identifiers when they contain characters outside the ASCII character set, for example Jörg, François, Łukasz, Алексей, 李明 or 山田太郎.

I propose adding a configuration option that keeps the current ASCII-only behavior by default, but allows administrators to opt in to Unicode usernames.

When enabled, usernames should follow the identifier rules defined by Unicode Standard Annex #31 (UAX #31) rather than simply allowing arbitrary Unicode characters.

For example:

security:
  enableUnicodeUsernames: false

With the option disabled, existing behavior remains unchanged.

With the option enabled, usernames could contain Unicode identifier characters according to the selected UAX #31 profile.

Why is this feature valuable?

ASCII-only usernames are an unnecessary internationalization restriction.

Usernames are identifiers, and there is no fundamental reason why an identifier in a modern UTF-8 application must be limited to the Latin alphabet without diacritics. Requiring users to replace or transliterate their names can be especially inconvenient for users whose names naturally use non-ASCII or non-Latin characters.

There are also established precedents in other self-hosted applications:

• Moodle provides an explicit setting to allow extended characters in usernames.
• Discourse supports Unicode usernames behind a configuration option and considers the associated Unicode/security implications explicitly.
• Jellyfin also supports Unicode characters in usernames.

This suggests that Unicode usernames are a practical feature rather than an unusual edge case.

At the same time, I would not recommend simply accepting arbitrary Unicode characters. Unicode introduces issues such as invisible characters, punctuation, normalization and visually confusable characters.

Using UAX #31 provides a standardized basis for deciding which characters are appropriate for identifiers. This is preferable to maintaining a custom and incomplete character whitelist.

An opt-in approach also preserves backwards compatibility and avoids changing the behavior of existing installations.

Another relevant consideration is that internationalized email addresses are already standardized through SMTPUTF8 / RFC 6531. While email addresses and application usernames are different concepts, this demonstrates that non-ASCII identifiers are well-established in modern identity systems.

Suggested Implementation

Add a configuration option similar to:

security:
  enableUnicodeUsernames: false

When disabled, the current username validation should remain unchanged.

When enabled, validate usernames according to a documented UAX #31 profile, preferably using the XID_Start / XID_Continue properties.

Conceptually:

username = XID_Start XID_Continue*

The implementation should explicitly define Unicode normalization/equality behavior as well, so that canonically equivalent representations cannot unexpectedly result in separate accounts.

The validation should reject inappropriate characters such as:

• whitespace
• control characters
• arbitrary punctuation
• invisible/format characters where not permitted by the selected identifier profile

The exact set of allowed characters should therefore come from the chosen UAX #31 profile rather than a manually maintained list.

The feature should be covered by tests for examples such as:

Jörg
François
Łukasz
Алексей
Αλέξανδρος
李明
山田太郎
أحمد

as well as negative cases involving whitespace, control characters, punctuation and problematic invisible characters.

Keeping the feature disabled by default would allow this to be introduced without affecting existing installations or integrations that assume ASCII usernames.

Additional Information

Useful references and prior art:

• Unicode Standard Annex #31 — Unicode Identifier and Pattern Syntax:
  https://www.unicode.org/reports/tr31/
• Moodle — extended characters in usernames:
  https://docs.moodle.org/31/en/Site_policies
• Discourse — Unicode usernames and group names:
  https://meta.discourse.org/t/unicode-usernames-and-group-names/117737
• RFC 6531 — SMTP Extension for Internationalized Email:
  https://www.rfc-editor.org/rfc/rfc6531.html

The key proposal is therefore not to "allow any Unicode", but to provide a controlled, opt-in Unicode username policy based on UAX #31, while retaining the existing ASCII-only behavior by default.

Example Files

Not applicable. This feature does not depend on specific PDF or example files.

No Duplicate of the Feature

• I have verified that there are no existing features requests similar to my request.