mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-07-15 18:12:14 -05:00
[GH-ISSUE #7086] Unable to automatically register and log in to accounts via SSO after versions 1.35.5/1.35.6 #30098
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/vaultwarden#30098
Reference in New Issue
Block a user
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?
Originally created by @TacKana on GitHub (Apr 13, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/7086
Prerequisites
Vaultwarden Support String
`### Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Environment settings which are overridden: ADMIN_TOKEN
Config:
Vaultwarden Build Version
v1.35.6
Deployment method
Official Container Image
Custom deployment method
services:
postgres:
container_name: ${SERVER_NAME}-postgres
image: postgres:18
restart: always
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB}
POSTGRES_USER: ${POSTGRES_USER}
volumes:
- pg_data:/var/lib/postgresql
- /etc/localtime:/etc/localtime:ro
ports:
- "${POSTGRES_PORT}:5432"
networks:
- vaultwarden_net # 使用固定名称
labels:
createdBy: "Apps"
vaultwarden:
container_name: ${SERVER_NAME}
image: vaultwarden/server:latest
depends_on:
postgres:
condition: service_healthy
environment:
- ROCKET_PORT=8080
- DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres/${POSTGRES_DB}
- ADMIN_TOKEN=${ADMIN_TOKEN}
- PUSH_ENABLED=true
- PUSH_INSTALLATION_ID=${PUSH_INSTALLATION_ID}
- PUSH_INSTALLATION_KEY=${PUSH_INSTALLATION_KEY}
- PUSH_RELAY_URI=https://api.bitwarden.eu
- PUSH_IDENTITY_URI=https://identity.bitwarden.eu
ports:
- 127.0.0.1:${VAULTWARDEN_PORT}:8080
volumes:
- vw_data:/data
restart: always
networks:
- vaultwarden_net
networks:
vaultwarden_net:
driver: bridge
name: ${SERVER_NAME}_net #
volumes:
pg_data:
name: ${SERVER_NAME}_pg_data
vw_data:
name: ${SERVER_NAME}_vw_data
Reverse Proxy
1panel/openresty:1.27.1.2-5-1-focal
Host/Server Operating System
Linux
Operating System Version
Debian GNU/Linux 13
Clients
Web Vault
Client Version
Web Installed 2026.2.0
Steps To Reproduce
I don't know
Expected Result
Normal login and registration via SSO
Actual Result
Before version 1.35.5, users were able to register and log in to their accounts via SSO on their own. However, after version 1.35.5, when users log in or register an account through SSO, an error prompt without detailed information briefly appears in the upper right corner of the page after redirection, and then the page redirects to the login page. I consider this a BUG, as I did not make any configuration changes from version 1.35.4 to 1.35.5/6; I only updated the Vaultwarden version to 1.35.5/6.
The detailed information generated is as follows
Logs
Screenshots or Videos
No response
Additional Context
主机名称: localhost
发行版本: Debian GNU/Linux 13
内核版本: 6.12.74+deb13+1-cloud-amd64
系统类型: x86_64
主机地址: *********
启动时间: 2026-04-13 11:53:07
运行时间: 15分钟 49秒
@BlackDex commented on GitHub (Apr 13, 2026):
Can you provide logs of Vaultwarden when these issues happen? The current logs do not provide these information.
What i see currently is that your Vaultwarden isn't able to connect to the internet. That might also prevent Vaultwarden from connecting to your SSO provider and cause your issues.
@TacKana commented on GitHub (Apr 13, 2026):
Hello, do you have an email address? I will send the logs to you. I am worried that sending them here will leak sensitive information. Also, my server can access the Internet, but due to its physical location in Chinese Mainland, it sometimes fails to connect to the vaultwarden update server.
@TacKana commented on GitHub (Apr 13, 2026):
bitwardenFree-20260413124929.log
@TacKana commented on GitHub (Apr 13, 2026):
@BlackDex
@BlackDex commented on GitHub (Apr 13, 2026):
Maybe @Timshel can see what a possible issue could be here?
It mentions invalid grant/token. Not sure if that could also be an issue on the SSO Provider side.
@Timshel commented on GitHub (Apr 13, 2026):
@BlackDex looking at it, I can reproduce similar scenario but with a different error.
The guard on
get_master_password_policyfail when it's called with a dummy orguuidgiven byget_auto_enroll_statuswhen called with theFAKE_IDENTIFIER. This was used to return a global MasterPassword policy which could be set in config.The guard was added in
787822854c, but I'm unsure how critical it is to protect this endpoint.@BlackDex commented on GitHub (Apr 13, 2026):
The reason for the Guard is that you could be able to extract the policy set by the organization and then use that for a brute-force tool to have a better understanding of what to the range or chars are they can use.
Seeing the comments in the
get_auto_enroll_status, that it will be mainly ignored does that mean it will never return anything useful for theFAKE_IDENTIFIER, in that case we might be able to detect specific identifier, and act upon that, so, that call still goes through, but then later just returns something different. Or, not sure if that is an option, create a different endpoint-function for this specific use-case?@Timshel commented on GitHub (Apr 13, 2026):
@BlackDex yes it does make brute force a little bit simpler but at the same time password policies are often public.
Alternatively I was thinking just removing the guard but checking membership in
get_master_password_policy.And if it does not match returning the default for SSO or otherwise nothing intead of a
401.@BlackDex commented on GitHub (Apr 13, 2026):
Wouldn't it be that simple as creating a custom endpoint
/organizations/VW_DUMMY_IDENTIFIER_FOR_OIDC/policies/master-passwordwith fnget_master_password_policy_dummy_oidcor something like this?That should still provide the security for real organizations and still working for SSO stuff.
@Timshel commented on GitHub (Apr 13, 2026):
@BlackDex the issue is the endpoint use an org uuid (
get_auto_enroll_statusreturn a random value), so it would mean hardcoding anotheruuid.Edit: I'll remark that for org we are using the
uuidas Identifier so converting the dummy identifier to anuuidwould make sense.@TacKana commented on GitHub (Apr 13, 2026):
The SSO provider I use is Casdoor with version: v2.400.0
@TacKana commented on GitHub (Apr 14, 2026):
@Timshel @BlackDex
Could you please tell me what caused the problem? It seems that version 1.35.7 hasn't fixed it either, and I want to know if there is a way to restore normal functionality now.
@ghost commented on GitHub (Apr 14, 2026):
Just to chime in, we are experiencing a the same issue with this update.
New users created via SSO get stuck in an "Invited" status and are unable to "Join the organization" despite not actually attempting to join any organization.
@Timshel commented on GitHub (Apr 14, 2026):
@BlackDex I'll prepare a patch with the custom endpoint and change the dummy identifier.
@JoeBiboche commented on GitHub (Apr 14, 2026):
Same issue here on a newly created Vaultwarden instance connected to Zitadel SSO. New users are unable to finalize the signup process. Tested with 1.35.5 and 1.35.7 version. 1.35.4 is working fine.
@MogCH commented on GitHub (Apr 20, 2026):
Hello, i have the same error on 1.35.7.
When will a fix be available, or is there a manual workaround ?
@BlackDex @Jeanot38 ?
@BlackDex commented on GitHub (Apr 20, 2026):
It's available in
:testingright now. We do not have specific ETA's for releases.@manduted commented on GitHub (Apr 22, 2026):
Then we need to temporarily roll back and use version 1.35.4 or the current :testing version, right?
@Timshel commented on GitHub (Apr 22, 2026):
@manduted Since
1.35.5contains multiple security fixes and depending ontestingis unstable, I would use a sha256 ref from thetestingrelease built onApr 16, 2026.@JoeBiboche commented on GitHub (Apr 22, 2026):
Working fine on a newly created instance with :testing version (Docker image). What about production instances ? Would be nice to have a way to patch security fixes related to 1.35.5 version and dealing with SSO issue fixed through this issue.
Thanks a lot !
@manduted commented on GitHub (Apr 23, 2026):
Oh, I remember you now. Back when Vaultwarden didn’t support OIDC, you created a branch to add that feature, and I’ve been using your Docker image ever since. Unfortunately, I had to completely reinstall my system and lost track of you. I only realized a couple of days ago that Vaultwarden now supports OIDC officially, but I still really appreciate what you did.
Since you’ve said that, I’ll go with :testing.
@Timshel commented on GitHub (Apr 24, 2026):
@manduted still around ;), still maintaining a soft fork waiting for additional features to be merged (roles + groups).