starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: OIDC: email_verified in JWT payload is only checked when creating a new account in ABS, not checked with existing accounts #3091

New Issue
Closed
opened 2026-04-25 00:13:37 +02:00 by adam · 3 comments
adam commented 2026-04-25 00:13:37 +02:00
Owner
Copy Link
Copy Source

Originally created by @ZLoth on GitHub (Nov 14, 2025).

What happened?

As observed in https://github.com/advplyr/audiobookshelf/issues/4794 , if the field/value email_verified: false is passed in the OIDC JWT payload, a new account cannot be created on ABS as designed. However, existing accounts are about to login.

What did you expect to happen?

Pre-existing accounts should follow behavior of new accounts and provide an "Unauthorized" message in the login screen if email_verified: false is part of the OIDC JWT payload.

Steps to reproduce the issue

See https://github.com/advplyr/audiobookshelf/issues/4794

Audiobookshelf version

2.30

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Chrome

Logs

See https://github.com/advplyr/audiobookshelf/issues/4794

Additional Notes

Filing defect to see if this is intended behavior. If it is, possible feature enhancement.

Originally created by @ZLoth on GitHub (Nov 14, 2025). ### What happened? As observed in https://github.com/advplyr/audiobookshelf/issues/4794 , if the field/value `email_verified: false` is passed in the OIDC JWT payload, a new account cannot be created on ABS as designed. However, existing accounts are about to login. ### What did you expect to happen? Pre-existing accounts should follow behavior of new accounts and provide an "Unauthorized" message in the login screen if `email_verified: false` is part of the OIDC JWT payload. ### Steps to reproduce the issue See https://github.com/advplyr/audiobookshelf/issues/4794 ### Audiobookshelf version 2.30 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Chrome ### Logs ```shell See https://github.com/advplyr/audiobookshelf/issues/4794 ``` ### Additional Notes Filing defect to see if this is intended behavior. If it is, possible feature enhancement.
adam added the bug label 2026-04-25 00:13:37 +02:00
adam closed this issue 2026-04-25 00:13:37 +02:00
adam commented 2026-04-25 00:13:37 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Nov 14, 2025):

I would not consider this a bug, as the user had to have a verified email. There is no chance to map another user that has an unverified.

On top this would break every Authentik instance instead of just the ones that did not create new users.

Maybe I overlook something, but how can an email address (out side of this situation, after it was verified at least once) be unverified again?

@Vito0912 commented on GitHub (Nov 14, 2025): I would not consider this a bug, as the user had to have a verified email. There is no chance to map another user that has an unverified. On top this would break every Authentik instance instead of just the ones that did not create new users. Maybe I overlook something, but how can an email address (out side of this situation, after it was verified at least once) be unverified again?
adam commented 2026-04-25 00:13:37 +02:00
Author
Owner
Copy Link
Copy Source

@ZLoth commented on GitHub (Nov 14, 2025):

Maybe I overlook something, but how can an email address (out side of this situation, after it was verified at least once) be unverified again?

It depends on what the OIDC provider is sending over as email_verified value as part of the JWT payload. As determined by the original defect, Authenik was hard-coding the value as either true prior to 2025.10 or false starting in 2025.10 . It's a security thing.

@ZLoth commented on GitHub (Nov 14, 2025): > Maybe I overlook something, but how can an email address (out side of this situation, after it was verified at least once) be unverified again? It depends on what the OIDC provider is sending over as `email_verified` value as part of the JWT payload. As determined by the original defect, Authenik was hard-coding the value as either true prior to 2025.10 or false starting in 2025.10 . It's a security thing.
adam commented 2026-04-25 00:13:37 +02:00
Author
Owner
Copy Link
Copy Source

@ZLoth commented on GitHub (Nov 14, 2025):

Closing as it is working as designed. Enhancement request submitted.

@ZLoth commented on GitHub (Nov 14, 2025): Closing as it is working as designed. Enhancement request submitted.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#3091
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?