[Bug]: Error in OIDC authentication - Unable to retrieve required values (email, name) #569

New Issue

OVERLORD · 2026-02-04T20:23:31+03:00

OVERLORD commented

2026-02-04 20:23:31 +03:00

Originally created by @marcomatrella on GitHub (Sep 20, 2024).

Current behaviour

I'm using OIDC authentication connecting to my tenant on Azure AD.

When I create a new user on my Azure Organization, I setup the username (that corresponds to the email_address of the user in my company), and I don't setup other details like email contact etc.

What I want to do is to set, in the parameter OIDC_EMAIL_ADDRESS (used, I think, to match on db table user_accounts and create a new user if it doesn't exists) the claim preferred_username or upn or unique_name as the email address of the user.

Here's the configuration I'm using in .env file :

######################################################### OIDC_ISSUER=https://login.microsoftonline.com/<my_tenant>/v2.0 OIDC_CLIENT_ID=<my_client_id> OIDC_CLIENT_SECRET=<my_client_secret> OIDC_IGNORE_ROLES=true OIDC_IGNORE_USERNAME=true OIDC_SCOPES=openid profile email OIDC_ENFORCED=true OIDC_EMAIL_ATTRIBUTE=upn ########################################################

(I made some tries changing the OIDC_EMAIL_ATTRIBUTE with the claim preferred_username, unique_name, etc, with no luck..)

When I start Planka and I try to login, I get the error :

{ "code": "E_UNPROCESSABLE_ENTITY", "message": "Unable to retrieve required values (email, name)" }

If I try to execute manually the OIDC authentication flow (through Postman, for example) I obtain a JWT token and I can see that the attributes upn, preferred_username, unique_name, etc exists and are correct.

The questions are :

What am I doing wrong here?
Is there a way to better debug/understand what is missing, like logging somewhere the full JWT token received?
Are you planning to add a stronger compatibility for authentication with Azure AD?

Originally created by @marcomatrella on GitHub (Sep 20, 2024). ### Current behaviour I'm using OIDC authentication connecting to my tenant on Azure AD. When I create a new user on my Azure Organization, I setup the username (that corresponds to the email_address of the user in my company), and I don't setup other details like email contact etc. What I want to do is to set, in the parameter OIDC_EMAIL_ADDRESS (used, I think, to match on db table user_accounts and create a new user if it doesn't exists) the claim **preferred_username** or **upn** or **unique_name** as the email address of the user. Here's the configuration I'm using in .env file : `######################################################### OIDC_ISSUER=https://login.microsoftonline.com/<my_tenant>/v2.0 OIDC_CLIENT_ID=<my_client_id> OIDC_CLIENT_SECRET=<my_client_secret> OIDC_IGNORE_ROLES=true OIDC_IGNORE_USERNAME=true OIDC_SCOPES=openid profile email OIDC_ENFORCED=true OIDC_EMAIL_ATTRIBUTE=upn ########################################################` _(I made some tries changing the OIDC_EMAIL_ATTRIBUTE with the claim preferred_username, unique_name, etc, with no luck..)_ When I start Planka and I try to login, I get the error : `{ "code": "E_UNPROCESSABLE_ENTITY", "message": "Unable to retrieve required values (email, name)" }` If I try to execute manually the OIDC authentication flow (through Postman, for example) I obtain a JWT token and I can see that the attributes upn, preferred_username, unique_name, etc exists and are correct. The questions are : - What am I doing wrong here? - Is there a way to better debug/understand what is missing, like logging somewhere the full JWT token received? - Are you planning to add a stronger compatibility for authentication with Azure AD?

OVERLORD closed this issue

2026-02-04 20:23:35 +03:00

OVERLORD commented

2026-02-04 20:23:43 +03:00

@marcomatrella commented on GitHub (Sep 20, 2024):

I made some tries downloading Planka source code and adding some logs to see what was wrong.

I added some logs in get-or-create-one-using-oidc.js to log what's inside the object converted by the library :

sails.log.error("********************************"); sails.log.error("Token : "); sails.log.error(JSON.stringify(userInfo));

In the console seems like tue object userInfo has only a minimal part of the informations contained in the id_token :

{"sub":"X3lvYEwdMkx......","name":"Nome Cognome","family_name":"Cognome","given_name":"Nome","picture":"https://graph.microsoft.com/v1.0/me/photo/$value"}

As you can see, there are few informations, for example there's not the preferred_username or upn claim.

So, after this, just before the assignment userInfo = await client.userinfo(tokenSet); i logged the object tokenSet :

sails.log.error("********************************"); sails.log.error("Tokenset : "); sails.log.error(JSON.stringify(tokenSet));

As expected, the tokenset contains both the access_token and id_token and they contains all the informations contained in the standard JWT token.

Reading the documentation of the library openid-client, there's a method that I can call to convert the claims contained in the id_token.
I added just few logs :
sails.log.error("********************************"); sails.log.error("Tokenset CLAIMS : "); sails.log.error(JSON.stringify(tokenSet.claims()));

And the claims contains everything I need, as you can see above :

{ "aio": "...", "aud": "...", "exp": 1726792881, "iat": 1726788981, "iss": "https://login.microsoftonline.com/<my_tenant>/v2.0", "name": "Nome Cognome", "nbf": ..., "nonce": "<nonce>", "oid": "<oid>", "preferred_username": "nome.cognome@<mycompany>.it", "rh": "<rh>", "sub": "<sub>", "tid": "<tid>", "upn": "nome.cognome@<mycompany>.it", "uti": "<uti>", "ver": "2.0" }

So, what I think is that there are 2 possibilities:

There is a conversion problem in the library openid-client used by Planka that, when converts the id_token in the object userInfo, it ignores the 80% of the claims contained in the id_token (client.userinfo(tokenSet))
There is some wrong configurations that I made, that I cannot understand..

For sure, both id_token and access_token contains all the informations that I was expecting.

@marcomatrella commented on GitHub (Sep 20, 2024): I made some tries downloading Planka source code and adding some logs to see what was wrong. I added some logs in `get-or-create-one-using-oidc.js` to log what's inside the object converted by the library : ` sails.log.error("********************************"); sails.log.error("Token : "); sails.log.error(JSON.stringify(userInfo)); ` In the console seems like tue object **userInfo** has only a minimal part of the informations contained in the id_token : `{"sub":"X3lvYEwdMkx......","name":"Nome Cognome","family_name":"Cognome","given_name":"Nome","picture":"https://graph.microsoft.com/v1.0/me/photo/$value"}` As you can see, there are few informations, for example there's not the **preferred_username** or **upn** claim. So, after this, just before the assignment `userInfo = await client.userinfo(tokenSet);` i logged the object **tokenSet** : `sails.log.error("********************************"); sails.log.error("Tokenset : "); sails.log.error(JSON.stringify(tokenSet));` As expected, the tokenset contains both the **access_token** and **id_token** and they contains all the informations contained in the standard JWT token. Reading the documentation of the library **openid-client**, there's a method that I can call to convert the claims contained in the id_token. I added just few logs : `sails.log.error("********************************"); sails.log.error("Tokenset CLAIMS : "); sails.log.error(JSON.stringify(tokenSet.claims()));` And the claims contains everything I need, as you can see above : `{ "aio": "...", "aud": "...", "exp": 1726792881, "iat": 1726788981, "iss": "https://login.microsoftonline.com/<my_tenant>/v2.0", "name": "Nome Cognome", "nbf": ..., "nonce": "<nonce>", "oid": "<oid>", "preferred_username": "nome.cognome@<mycompany>.it", "rh": "<rh>", "sub": "<sub>", "tid": "<tid>", "upn": "nome.cognome@<mycompany>.it", "uti": "<uti>", "ver": "2.0" }` So, what I think is that there are 2 possibilities: - There is a conversion problem in the library **openid-client** used by Planka that, when converts the id_token in the object userInfo, it ignores the 80% of the claims contained in the id_token (`client.userinfo(tokenSet)`) - There is some wrong configurations that I made, that I cannot understand.. For sure, both id_token and access_token contains all the informations that I was expecting.

OVERLORD commented

2026-02-04 20:23:46 +03:00

@marcomatrella commented on GitHub (Sep 20, 2024):

I create a PR to solve this issue :

https://github.com/plankanban/planka/pull/885

@marcomatrella commented on GitHub (Sep 20, 2024): I create a PR to solve this issue : [https://github.com/plankanban/planka/pull/885](url)

OVERLORD commented

2026-02-04 20:23:51 +03:00

@meltyshev commented on GitHub (Sep 20, 2024):

Hi! Thanks for reporting this and for the investigation you've done. I think a better fix might be to allow skipping the userinfo endpoint request entirely (by setting an additional environment variable) and instead take all claims from the id_token. This could also potentially resolve https://github.com/plankanban/planka/issues/872, where the userinfo endpoint isn't configured.

UPD: I'll make a few adjustments to your PR if you don't mind :)

@meltyshev commented on GitHub (Sep 20, 2024): Hi! Thanks for reporting this and for the investigation you've done. I think a better fix might be to allow skipping the userinfo endpoint request entirely (by setting an additional environment variable) and instead take all claims from the id_token. This could also potentially resolve https://github.com/plankanban/planka/issues/872, where the userinfo endpoint isn't configured. UPD: I'll make a few adjustments to your PR if you don't mind :)

OVERLORD commented

2026-02-04 20:24:00 +03:00

@marcomatrella commented on GitHub (Sep 20, 2024):

Hi! Thanks for reporting this and for the investigation you've done. I think a better fix might be to allow skipping the userinfo endpoint request entirely (by setting an additional environment variable) and instead take all claims from the id_token. This could also potentially resolve #872, where the userinfo endpoint isn't configured.

UPD: I'll make a few adjustments to your PR if you don't mind :)

Totally agree. I saw that you already made the fix in my repo, I'll test and eventually the PR

@marcomatrella commented on GitHub (Sep 20, 2024): > Hi! Thanks for reporting this and for the investigation you've done. I think a better fix might be to allow skipping the userinfo endpoint request entirely (by setting an additional environment variable) and instead take all claims from the id_token. This could also potentially resolve #872, where the userinfo endpoint isn't configured. > > UPD: I'll make a few adjustments to your PR if you don't mind :) Totally agree. I saw that you already made the fix in my repo, I'll test and eventually the PR

OVERLORD commented

2026-02-04 20:24:06 +03:00

@marcomatrella commented on GitHub (Sep 20, 2024):

@meltyshev I had to close the old PR and create a new one cause of a problem with my username/email with which I pushed on my repo. I restored all files pushed from me and you, and created the new PR : https://github.com/plankanban/planka/pull/888

Sorry for the inconvenience

@marcomatrella commented on GitHub (Sep 20, 2024): @meltyshev I had to close the old PR and create a new one cause of a problem with my username/email with which I pushed on my repo. I restored all files pushed from me and you, and created the new PR : [https://github.com/plankanban/planka/pull/888](url) Sorry for the inconvenience

OVERLORD referenced this issue

2026-02-04 21:46:23 +03:00

[PR #569] [MERGED] fix zh translation of 1.15.2 version #1048

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#569