[PR #7127] Add SSO cookie vendor endpoint for native apps behind auth proxies #20760

Open
opened 2026-04-25 22:43:03 -05:00 by GiteaMirror · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/dani-garcia/vaultwarden/pull/7127
Author: @nathanmoreton
Created: 4/24/2026
Status: 🔄 Open

Base: mainHead: feat/sso-cookie-vendor


📝 Commits (2)

  • 2b79525 Add SSO cookie vendor endpoint for native apps behind authenticating proxies
  • 88b0ba0 Merge branch 'dani-garcia:main' into feat/sso-cookie-vendor

📊 Changes

5 files changed (+493 additions, -0 deletions)

View changed files

📝 .env.template (+22 -0)
docs/sso-cookie-vendor.md (+180 -0)
📝 src/api/core/mod.rs (+19 -0)
src/api/core/sso_cookie_vendor.rs (+251 -0)
📝 src/config.rs (+21 -0)

📄 Description

Native Bitwarden apps cannot complete login when Vaultwarden sits behind an authenticating reverse proxy (Cloudflare Access, Authentik, Authelia, oauth2-proxy). The proxy redirects API requests to a browser-based IdP flow, which the apps' HTTP clients cannot follow.

Bitwarden addressed this upstream in February 2026 with a flow called SSO cookie vending. The server publishes, through /api/config, a communication.bootstrap block naming the IdP login URL and the cookie the proxy sets. The app opens a system browser for the IdP step, the browser hits /api/sso-cookie-vendor, and the server 302-redirects to bitwarden://sso-cookie-vendor?<name>=<value>&d=1. The app captures the cookie from the deep link and attaches it to every future API request.

Vaultwarden v2026.2.0 shipped the web-vault connector page from clients#18476, but the server side has not landed. This PR adds it.

Changes

  • New config section sso_cookie_vendor through the existing make_config! macro: SSO_COOKIE_VENDOR_ENABLED, SSO_COOKIE_VENDOR_IDP_LOGIN_URL, SSO_COOKIE_VENDOR_COOKIE_NAME, SSO_COOKIE_VENDOR_COOKIE_DOMAIN. Startup validation refuses to run when the flag is on but the three string fields are empty.
  • GET /api/sso-cookie-vendor reads the proxy auth cookie from the request jar and 302-redirects to the bitwarden:// deep link. Handles sharded cookies (<name>-0 through <name>-19, which Cloudflare Access uses when the JWT exceeds single-cookie size limits), with a non-sharded cookie taking precedence. Missing cookie returns the upstream 404 HTML page; URIs over 8192 bytes return 400. Registered only when the flag is on.
  • communication.bootstrap object added to /api/config, matching the shape from upstream PR #6892 so clients pick it up unpatched.
  • Unit tests cover single-cookie, sharded-cookie, precedence, URL-encoding, oversize URI, missing-cookie 404, and error HTML format.
  • docs/sso-cookie-vendor.md covers the end-to-end flow, security notes, and per-proxy configuration.

Default behavior

SSO_COOKIE_VENDOR_ENABLED defaults to false. Installs without the four env vars set are byte-identical to current behavior.

Upstream references

Test plan

  • cargo fmt --check
  • cargo clippy --features sqlite -- -D warnings
  • cargo test --features sqlite -- sso_cookie_vendor
  • Manual: running behind Cloudflare Access with the four env vars set; web vault and native iOS/Android/desktop apps all complete login.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/dani-garcia/vaultwarden/pull/7127 **Author:** [@nathanmoreton](https://github.com/nathanmoreton) **Created:** 4/24/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `feat/sso-cookie-vendor` --- ### 📝 Commits (2) - [`2b79525`](https://github.com/dani-garcia/vaultwarden/commit/2b79525441a4e2376bde9ebdef850c835e21bc9b) Add SSO cookie vendor endpoint for native apps behind authenticating proxies - [`88b0ba0`](https://github.com/dani-garcia/vaultwarden/commit/88b0ba060ea9f932e1cadd57c602e0aa70aa82c0) Merge branch 'dani-garcia:main' into feat/sso-cookie-vendor ### 📊 Changes **5 files changed** (+493 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `.env.template` (+22 -0) ➕ `docs/sso-cookie-vendor.md` (+180 -0) 📝 `src/api/core/mod.rs` (+19 -0) ➕ `src/api/core/sso_cookie_vendor.rs` (+251 -0) 📝 `src/config.rs` (+21 -0) </details> ### 📄 Description Native Bitwarden apps cannot complete login when Vaultwarden sits behind an authenticating reverse proxy (Cloudflare Access, Authentik, Authelia, oauth2-proxy). The proxy redirects API requests to a browser-based IdP flow, which the apps' HTTP clients cannot follow. Bitwarden addressed this upstream in February 2026 with a flow called SSO cookie vending. The server publishes, through `/api/config`, a `communication.bootstrap` block naming the IdP login URL and the cookie the proxy sets. The app opens a system browser for the IdP step, the browser hits `/api/sso-cookie-vendor`, and the server 302-redirects to `bitwarden://sso-cookie-vendor?<name>=<value>&d=1`. The app captures the cookie from the deep link and attaches it to every future API request. Vaultwarden v2026.2.0 shipped the web-vault connector page from `clients#18476`, but the server side has not landed. This PR adds it. ## Changes - New config section `sso_cookie_vendor` through the existing `make_config!` macro: `SSO_COOKIE_VENDOR_ENABLED`, `SSO_COOKIE_VENDOR_IDP_LOGIN_URL`, `SSO_COOKIE_VENDOR_COOKIE_NAME`, `SSO_COOKIE_VENDOR_COOKIE_DOMAIN`. Startup validation refuses to run when the flag is on but the three string fields are empty. - `GET /api/sso-cookie-vendor` reads the proxy auth cookie from the request jar and 302-redirects to the `bitwarden://` deep link. Handles sharded cookies (`<name>-0` through `<name>-19`, which Cloudflare Access uses when the JWT exceeds single-cookie size limits), with a non-sharded cookie taking precedence. Missing cookie returns the upstream 404 HTML page; URIs over 8192 bytes return 400. Registered only when the flag is on. - `communication.bootstrap` object added to `/api/config`, matching the shape from upstream PR #6892 so clients pick it up unpatched. - Unit tests cover single-cookie, sharded-cookie, precedence, URL-encoding, oversize URI, missing-cookie 404, and error HTML format. - `docs/sso-cookie-vendor.md` covers the end-to-end flow, security notes, and per-proxy configuration. ## Default behavior `SSO_COOKIE_VENDOR_ENABLED` defaults to `false`. Installs without the four env vars set are byte-identical to current behavior. ## Upstream references - bitwarden/server#6880: config infrastructure - bitwarden/server#6892: expose config in `/api/config` - bitwarden/server#6903: endpoint implementation - bitwarden/clients#18476: web-vault connector page (already in Vaultwarden v2026.2.0) - bitwarden/clients#19392: client-side cookie acquisition ## Test plan - `cargo fmt --check` - `cargo clippy --features sqlite -- -D warnings` - `cargo test --features sqlite -- sso_cookie_vendor` - Manual: running behind Cloudflare Access with the four env vars set; web vault and native iOS/Android/desktop apps all complete login. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-25 22:43:03 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#20760