[Bug]: OIDC_USERNAME_ATTRIBUTE variable seems to be ignored

[haukebruno]

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

[intersecato]

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.

[meltyshev]

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).

[haukebruno]

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?