SSO bugs: still always auth_header basic password injected & apps that need basic-email as login broken?

tmb · September 26, 2026, 9:24am

I have searched the forum for similar issues

on

This category is for general issues(=something is broken) regarding YunoHost, NOT apps.

on

This form is written in English but feel free to write in French if you’re more comfortable!

on

What type of hardware are you using

Virtual machine

What YunoHost version are you running

12.1.41.2

How are you able to access your server

The webadmin

Describe your issue

(For a bullet point list of the little “tasks” found, see later post below.)

After noticing “half working” SSO failures (like Login Mobilizon with LDAP is not so easy):

A “negative” workaround (seen here) seems to be to completely disable the SSO with an app manifest setting auth_header = false.

I see that setting does otherwise always default to "auth_header": "basic-with-password" in /etc/ssowat/conf.json. (Contrary to the comment “By default, the password is not injected anymore” it’s currently always overridden.)

[ EDIT: More precisely: the authorisation header is always overriden with auth_header and always injecting at least ‘-’ for a password. (No way to get SSO user headers without overriding the authorisation header (auth_header = false)? ]

Further, apps that use the the email as login identifier instead of the username (like mobilizon), wouldn’t these rather need a proper override like:
“auth_header”: “basic-email-with-password”? (if they really accept a (basic) auth_header for SSO)

(If they actually accept a basic auth_header for SSO.)

Share relevant logs or error messages

otm33 · September 26, 2026, 1:49pm

Afaiu, mobilizon generates a bearer token header which is overridden by sso (no matter what auth header is injected).

tmb · September 26, 2026, 2:26pm

Hm, sounds like another SSO bug! Because it sais:
-- Ignore if not a Basic auth header
( SSOwat/access.lua at a59b558bbbcaeb00199a19ce952bf3c75ce78bef · YunoHost/SSOwat · GitHub )

Maybe the header should only be cleared, if find(auth_header_from_client, "^Basic%s+(.+)$") ~~didn’t match anything~~actually mached something (check for not equal -1?), instead of clearing any auth if there is no basic auth credential ???

tmb · September 26, 2026, 2:42pm

Hm, current code might be working fine, as ~= nil means “not equal nil” in lua? So bearer tokens are actually not cleared?

(So remaining mobilizon and others SSO problem?: Just SSO basic auth containing username not email, and mobilizon thus wanting to create new profile?)

Question: How to use yunohost CLI to custom-override the nested auth header setting?:

/etc/yunohost/app/.../settings.yml:
 _permissions:
  main:
    auth_header: true

(trying to set _permission.main.auth_header did create a separate flat entry of that name)

otm33 · September 26, 2026, 2:51pm

In section 6, if auth_header = true or basic-with-password, a new authorization header is built and overrides the bearer token header.

tmb · September 26, 2026, 4:21pm

“gancio” likely suffers from exacly the same SSO bug(s) as “mobilizon” (confirming post: Gancio - only admin can login - #2 by esist0).

(YNH SSO login [header] breaks email-based app-login.)

otm33 · September 26, 2026, 4:30pm

Gancio does not use SSO nor LDAP. The admin user is created via the install script.

tmb · September 26, 2026, 5:13pm

I think currenly both, stand-alone and LDAP (plus SSO) apps require auth_header = false to not get their own auth headers cleared. And that setting will disable any [EDIT: standard auth-header-based] SSO (it stops working).

Seems indenpendent of users being managed by the app or in LDAP.

otm33 · September 26, 2026, 5:34pm

Well… that’s already the case for many applications indeed. When needed, of course.

tmb · September 26, 2026, 5:42pm

Not sure where auth_headers can actually work without breaking apps, maybe with old apps only using basic auth?

Most apps would probaly required to be configurable to honor default YNH_ proxy headers for SSO (SSO/LDAP integration | Yunohost) or need a custom nginx.conf to insert their accepted headers.

EDIT: Maybe change the default to ‘auth_headers = false’?

otm33 · September 26, 2026, 6:25pm

Take a look at /etc/nginx/proxy_params_no_auth and at the nginx conf for apps with auth_header set to true.

tmb · September 26, 2026, 6:55pm

I don’t quite understand what you try to explain, but the doc (SSO/LDAP integration | Yunohost) could sure use some checklist of settings to consider/set in case you know some.

It seems there are too many apps with login or SSO failing (leading e.g. to How to use single-sign on).

tmb · October 4, 2026, 7:26pm

Maybe the authorization header should only be set if the auth_header value matches basic*?

github.com/YunoHost/SSOwat

access.lua

a59b558bb


      
              -- (by default we use '-' as a dummy value though, otherwise the header doesn't work as expected..)
              local password = "-"
              if permission["auth_header"] == "basic-with-password" then
                  local password_enc_b64, iv_b64 = authPasswordEnc:match("([^|]+)|([^|]+)")
                  local password_enc = ngx.decode_base64(password_enc_b64)
                  local iv = ngx.decode_base64(iv_b64)
                  password = cipher.new('aes-256-cbc'):decrypt(COOKIE_SECRET, iv):final(password_enc)
              end
          
              -- Set `Authorization` header to enable HTTP authentification
              ngx.req.set_header("Authorization", "Basic "..ngx.encode_base64(
                  authUser..":"..password
              ))
          
              if authUserHeaders ~= nil then
                  for k, v in pairs(authUserHeaders) do
                      ngx.req.set_header(k, v)
                  end
              end
          end

tmb · October 5, 2026, 7:41pm

Hm, it certainly seems there are a few small things with larger impact that need some clean up / refactoring in Yunohost’s central SSO code.

SSOwat silently removes Basic Auth HTTP headers, which makes the problems it causes hard to debug. · Issue #2574 · YunoHost/issues · GitHub

SSOwat (?) clashes with HTTP Basic auth · Issue #2641 · YunoHost/issues · GitHub

Could be easy for someone fluent in python/lua:

Consider renaming protect_against_basic_auth_spoofing to clear_basic_auth_client_headers (just add it/document deprecation for now).
Consider removing the central override: apps_that_need_external_auth_maybe. (Let apps set protect_against_basic_auth_spoofing themselves as already documented, ideally according to e.g. their web/caldav client config panel setting.)
Consider letting auth_header = basic-mail-{with,without}-password insert email instead of username.
Stop always overriding basic auth with truthy auth_header setting, only override if auth_header matches basic* ). It currently moots protect_against_basic_auth_spoofing = false. Currently settings break either sso or webdav/caldav (app passwords).
Consider adjusting the http info header “You’ve just been SSOed” to be more informative, e.g. SSO-INFO: basic-auth-cleared/set, user-headers-set". (To make the default/configured behavior noticable on the client side?)

tmb · October 7, 2026, 6:27pm

Found an explanation, that might suggest a different approach to configuring the headers…

Set SSOWAT basic auth header stripping to false by RamanMalykhin · Pull Request #172 · YunoHost-Apps/calibreweb_ynh · GitHub :
This [clearing] behavior exists because some Ynh apps may want to be aware of different users and their profiles, but delegate the auth functionality entirely to SSOWat, do not integrate with LDAP in any way, and trust the header sent from SSOWat without verifying the password. Then, it would be possible to impersonate a user by setting the username manipulating the basic auth header, if this behavior did not exist.
However, this scenario is not relevant to Calibre-Web. It does check the password

If the desired/required behavior depends on how the headers are trusted by apps, then maybe apps shoud rather be specifically configuring (requesting) something like trusted-sso-basic-auth or client-provided-basic-auth, and trusted-sso-user-headers.

I.e. don’t hardcode sso-user-header and basic-auth clearing together, and clear only what would otherwise be wrong to trust?