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

New Issue

OVERLORD · 2025-10-09T18:34:14+03:00

OVERLORD commented

2025-10-09 18:34:14 +03:00

Originally created by @haukebruno on GitHub.

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. ### 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 commented

2025-10-09 18:34:16 +03:00

@intersecato commented on GitHub:

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: 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

2025-10-09 18:34:17 +03:00

@meltyshev commented on GitHub:

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: 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

2025-10-09 18:34:17 +03:00

@haukebruno commented on GitHub:

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: 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`?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#9