Map OIDC/OAuth2 avatar claims to user pictureUrl

[mod242]

This change maps common avatar claims from Generic OpenID Connect (and OAuth2) profiles to Wiki.js users. It now reads picture and avatar (including nested profile.* where present) and passes the value as profile.picture, which is the field already used by user processing. As a result, avatar URLs from standard OIDC claims are persisted to users.pictureUrl and shown in the UI after login.

Notes:

• No schema changes
• Requires server restart and re-login to update existing users

[Zappo-II]

Your the man, dude...
Exactly what I was missing and works directly within my environment...
THXalot

[NGPixel]

I would prefer a customizable claim field, rather than trying 5 different fields every time.

[mod242]

You are absolutely right, sorry for the overhead.
The last change replaces the hardcoded avatar field mapping with a configurable pictureClaim for both Generic OAuth2 and Generic OpenID Connect. The new setting defaults to picture and allows admins to specify any claim path used by their
provider. The value is mapped to profile.picture, which is already used to persist users.pictureUrl.

[Zappo-II]

@mod242 - Awesome, dude...

[NGPixel]

Thanks!

[antoniovalenzuela]

Hi
I enabled OAuth2

The login works! but calls https://graph.microsoft.com/v1.0/me/photo/$value (error 401) and the user icon is not visible

I have not been able to identify the origin of the call to prevent get the photo.

[mod242]

Hi,

I woul assume that the Problem in your setup is, that your oauth-provider delivers an picture claim, but instead to set it to a valid picture, it returns this URL which contains an variable and therefor delivers an 404.

Two things to solve this (hopefully):
Preferred: Configure your oauth provider to deliver an valid Picture claim (with a working URL)
Alternatively: Configure in Wikijs the Picture Claim to some none-existing value (e.g. 'NONE' instead of picture) so that you don't get any value.

Let me know if this helps.

[antoniovalenzuela]

Hi,

I woul assume that the Problem in your setup is, that your oauth-provider delivers an picture claim, but instead to set it to a valid picture, it returns this URL which contains an variable and therefor delivers an 404.

Two things to solve this (hopefully): Preferred: Configure your oauth provider to deliver an valid Picture claim (with a working URL) Alternatively: Configure in Wikijs the Picture Claim to some none-existing value (e.g. 'NONE' instead of picture) so that you don't get any value.

Let me know if this helps.

I can't find "avatar url"

[antoniovalenzuela]

Hi,
I woul assume that the Problem in your setup is, that your oauth-provider delivers an picture claim, but instead to set it to a valid picture, it returns this URL which contains an variable and therefor delivers an 404.
Two things to solve this (hopefully): Preferred: Configure your oauth provider to deliver an valid Picture claim (with a working URL) Alternatively: Configure in Wikijs the Picture Claim to some none-existing value (e.g. 'NONE' instead of picture) so that you don't get any value.

Let me know if this helps.

I can't find "avatar url"

I use this, OAuth2 with code_grant

[mod242]

I'll try to reproduce. But a short quesition: Your Oauth provider delivers an invalid URL as picture claim, correct?

[antoniovalenzuela]

I'll try to reproduce. But a short quesition: Your Oauth provider delivers an invalid URL as picture claim, correct?

The URL is valid, I'm using the Microsoft OAuth2, but the JWT isn't being sent. It returns a 401 Unauthorized error.

I'm replacing the provider, and I'm seeing other problems updating the data in the "users" database table:

duplicate key value violates unique constraint "users_providerkey_email_unique"

Some accounts log in perfectly, while others show the error.

Finally, I selected the "Generic OpenID Connect / OAuth2" provider. It works without problems; it doesn't claims photo, and there's no database error.

The "providerId" field is automatically replaced upon login.