[Bug]: OIDC_USERNAME_ATTRIBUTE variable seems to be ignored #825

New Issue

OVERLORD · 2026-02-04T21:25:25+03:00

OVERLORD commented

2026-02-04 21:25:25 +03:00

Originally created by @haukebruno on GitHub (Sep 27, 2025).

Where is the problem occurring?

I encountered the problem while interacting with the server (Backend)

What browsers are you seeing the problem on?

No response

Current behavior

While setting both env variables OIDC_USERNAME_ATTRIBUTE and OIDC_IGNORE_USERNAME=false the usernames of users synced from an IdP (Authentik in my case) aren't set on the user objects in the Planka database.

I tried a flat attribute like OIDC_USERNAME_ATTRIBUTE=foo and also a nested one like OIDC_USERNAME_ATTRIBUTE=attributes.custom_username.

Login still works, the users will be created but without the username.

I guess this isn't a problem at all while using Planka, but I'm still curious whether it is possible to sync also custom usernames from an IdP attribute to the Planka DB.

The default attribute preferred_username works like a charm, only custom ones don't.

Also logs don't point out anything (neither on the Planka nor on the IdP side).

Desired behavior

While having OIDC_IGNORE_USERNAME=false and OIDC_USERNAME_ATTRIBUTE=attributes.custom_username set and having something like "attributes" : { "custom_username" : "foo" } in the JWT payload, I'd expect to see the DB column username in the user_account table set to foo

Steps to reproduce

Set OIDC_IGNORE_USERNAME=false as env variable
Set OIDC_USERNAME_ATTRIBUTE=attributes.custom_username as env variable
Check that JWT payload of Authentik contains "attributes" : { "custom_username" : "foo" }
Perform Planka SSO login
Perform select id, email, updated_at,username from user_account; on the Planka DB

Other information

No response

Originally created by @haukebruno on GitHub (Sep 27, 2025). ### Where is the problem occurring? I encountered the problem while interacting with the server (Backend) ### What browsers are you seeing the problem on? _No response_ ### Current behavior While setting both env variables `OIDC_USERNAME_ATTRIBUTE` and `OIDC_IGNORE_USERNAME=false` the usernames of users synced from an IdP (Authentik in my case) aren't set on the user objects in the Planka database. I tried a flat attribute like `OIDC_USERNAME_ATTRIBUTE=foo` and also a nested one like `OIDC_USERNAME_ATTRIBUTE=attributes.custom_username`. Login still works, the users will be created but without the username. I _guess_ this isn't a problem at all while using Planka, but I'm still curious whether it is possible to sync also custom usernames from an IdP attribute to the Planka DB. The default attribute `preferred_username` works like a charm, only custom ones don't. Also logs don't point out anything (neither on the Planka nor on the IdP side). ### Desired behavior While having `OIDC_IGNORE_USERNAME=false` and `OIDC_USERNAME_ATTRIBUTE=attributes.custom_username` set and having something like `"attributes" : { "custom_username" : "foo" }` in the JWT payload, I'd expect to see the DB column `username` in the `user_account` table set to `foo` ### Steps to reproduce * Set `OIDC_IGNORE_USERNAME=false` as env variable * Set `OIDC_USERNAME_ATTRIBUTE=attributes.custom_username` as env variable * Check that JWT payload of Authentik contains `"attributes" : { "custom_username" : "foo" }` * Perform Planka SSO login * Perform `select id, email, updated_at,username from user_account;` on the Planka DB ### Other information _No response_

OVERLORD closed this issue

2026-02-04 21:25:30 +03:00

OVERLORD commented

2026-02-04 21:25:40 +03:00

@intersecato commented on GitHub (Sep 28, 2025):

I ran into this identical problem yesterday while setting up Auth0. I thought it was my problem and I'd look into it more carefully when I had more time. The fact that you've had the same problem reassures me.

@intersecato commented on GitHub (Sep 28, 2025): I ran into this identical problem yesterday while setting up Auth0. I thought it was my problem and I'd look into it more carefully when I had more time. The fact that you've had the same problem reassures me.

OVERLORD commented

2026-02-04 21:25:49 +03:00

@meltyshev commented on GitHub (Sep 30, 2025):

Hey! Thanks for reporting this.

I just tested providing a custom attribute for username - works fine for me (but not with nested ones, since we don't support that yet). The only issue I hit was when trying to use email as a username - validation fails on model level, since the regex for username is /^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/ (maybe also should be configurable).

@meltyshev commented on GitHub (Sep 30, 2025): Hey! Thanks for reporting this. I just tested providing a custom attribute for username - works fine for me (but not with nested ones, since we don't support that yet). The only issue I hit was when trying to use email as a username - validation fails on model level, since the regex for username is `/^[a-zA-Z0-9]+((_|\.)?[a-zA-Z0-9])*$/` (maybe also should be configurable).

OVERLORD commented

2026-02-04 21:25:52 +03:00

@haukebruno commented on GitHub (Oct 1, 2025):

Yeah, the initially reason to use a custom attribute for the username was that limitation that mail addresses aren't currently supported as usernames.

Out of curiosity: Are there other limitations? Our custom usernames will be just 2 chars, like "hw" or so. Maybe that's also limitting.

And just for my understanding: You tested a custom attribute that sits on the same level like for instance preferred_username?

@haukebruno commented on GitHub (Oct 1, 2025): Yeah, the initially reason to use a custom attribute for the username was that limitation that mail addresses aren't currently supported as usernames. Out of curiosity: Are there other limitations? Our custom usernames will be just 2 chars, like "hw" or so. Maybe that's also limitting. And just for my understanding: You tested a custom attribute that sits on the same level like for instance `preferred_username`?

OVERLORD commented

2026-02-04 21:25:58 +03:00

@petrholik commented on GitHub (Nov 20, 2025):

"Is there a specific technical reason for the current username constraints (the strict regex and the 16-character limit)?

This limitation causes issues with most OIDC providers, as they often return email addresses or longer identifiers as usernames.

If there are no objections, I would be happy to create a PR that updates the validation to accept emails as usernames."

@petrholik commented on GitHub (Nov 20, 2025): "Is there a specific technical reason for the current username constraints (the strict regex and the 16-character limit)? This limitation causes issues with most OIDC providers, as they often return email addresses or longer identifiers as usernames. If there are no objections, I would be happy to create a PR that updates the validation to accept emails as usernames."

OVERLORD commented

2026-02-04 21:26:02 +03:00

@meltyshev commented on GitHub (Dec 4, 2025):

Added object-path support.

Regarding using an email as a username: you can map the field containing the email to PLANKA's email field and skip usernames entirely. Usernames shouldn't contain the @ symbol, since we use it to determine whether to authenticate with email or username. And yes, we recently made some changes: relaxed the username regex for OIDC user creation and doubled the maximum length. Hopefully that should be enough :)

@meltyshev commented on GitHub (Dec 4, 2025): Added object-path support. Regarding using an email as a username: you can map the field containing the email to PLANKA's email field and skip usernames entirely. Usernames shouldn't contain the `@` symbol, since we use it to determine whether to authenticate with email or username. And yes, we recently made some changes: relaxed the username regex for OIDC user creation and doubled the maximum length. Hopefully that should be enough :)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#825