TypeError: sha1(): Argument #1 ($string) must be of type string, null given

I am trying to use SAML with Auth0. But I am getting this error. I am unable to see and find what is the resolution to this.

TypeError: sha1(): Argument #1 ($string) must be of type string, null given

  1. /var/www/nextcloud/lib/private/Authentication/Token/PublicKeyTokenProvider.php - line 116:sha1()
  2. /var/www/nextcloud/lib/private/Authentication/Token/Manager.php - line 69:OC\Authentication\Token\PublicKeyTokenProvider->generateToken(“*** sensiti … *”)
  3. /var/www/nextcloud/lib/private/User/Session.php - line 686:OC\Authentication\Token\Manager->generateToken(“*** sensiti … *”)
  4. /var/www/nextcloud/lib/private/legacy/OC_User.php - line 194:OC\User\Session->createSessionToken(“*** sensiti … *”)
  5. /var/www/nextcloud/lib/private/legacy/OC_User.php - line 243:OC_User::loginWithApache(“*** sensiti … *”)
  6. /var/www/nextcloud/lib/base.php - line 1122:OC_User::handleApacheAuth()
  7. /var/www/nextcloud/lib/base.php - line 1044:OC::handleLogin()
  8. /var/www/nextcloud/index.php - line 36:OC::handleRequest()
1 Like

Consider providing information about what exact Nextcloud version and what exact SAML app version you are on.

Same problem here after the upgrade to Nextcloud 26.0. I’m using Authentik as SAML provider.
SAML is added to Nextcloud exactly like in this tutorial: Complete guide to Nextcloud SAML authentication with Authentik · Jack's Blog

The first problem after upgrading to Nextcloud 26.0 seems to be the password policy app: Login with enabled password_policy and external provider SSO & SAML authentication fails for NC 26 · Issue #448 · nextcloud/password_policy · GitHub
After fixing this I got this error here:

TypeError: sha1(): Argument #1 ($string) must be of type string, null given
/var/www/html/lib/private/Authentication/Token/PublicKeyTokenProvider.php - line 116:

sha1(“*** sensiti … *”)

/var/www/html/lib/private/Authentication/Token/Manager.php - line 69:

OC\Authentication\Token\PublicKeyTokenProvider->generateToken(“*** sensiti … *”)

/var/www/html/lib/private/User/Session.php - line 686:

OC\Authentication\Token\Manager->generateToken(“*** sensiti … *”)

/var/www/html/lib/private/legacy/OC_User.php - line 194:

OC\User\Session->createSessionToken(“*** sensiti … *”)

/var/www/html/lib/private/legacy/OC_User.php - line 243:

OC_User::loginWithApache(“*** sensiti … *”)

/var/www/html/lib/base.php - line 1122:


/var/www/html/lib/base.php - line 1044:

OC::handleLogin(“*** sensiti … *”)

/var/www/html/index.php - line 36:


1 Like

I had this issue for some users and got it “fixed” in my 26.0.0 nextcloud instance. (this is a bug, but you can fix it with some workarounds)

In my situation we use LDAP as the only user backend. But actual logins use SAML SSO.

If a user has ever logged into nextcloud via ldap directly, using either the special direct login url ( https://nextcloud/index.php/login?direct=1 ), or via a direct WebDAV client connection (winscp in my test case), they will then begin to see the error above anytime they try to login via SAML from that point forward.

Something about the auth token that gets issued for the direct login is corrupt, and that user can then no longer login via SAML. They begin getting that error on all subsequent login attempts.

To fix:

Option 1 Fix a single user:

Delete ALL authtoken entries for the affected user: (note this logs them out of EVERYTHING, all desktop, browser, and mobile clients)

DELETE FROM oc_authtoken WHERE uid LIKE 'bob';

Option 2 - Fix for everyone in the nextcloud instance:

In my scenario, where saml is the only valid login type that should be allowed, i notice users that have the issue, their authtoken’s have a ‘password_hash’ value present, this seems to indicate the corruption is present, as the saml users shouldn’t have a password, nor password hash set since they don’t use passwords to login.

Here’s a full scale delete, that should only target the corrupt authtokens based on the presence of ‘password_hash’. Use with caution, you might log out a lot of client’s and sync clients with this. Make sure you then put in the ldap direct login uid block discussed down below to ensure the corruption doesn’t return. This logs out all direct login users too, like a local admin account.

Check the impact first with the select statement, shows the user and their devices name:

SELECT uid,login_name,name FROM oc_authtoken WHERE password_hash IS NOT NULL;

Delete the corrupt tokens for all users:

DELETE FROM oc_authtoken WHERE password_hash IS NOT NULL;

Prevent the bug from occurring again:

Workaround the issue while the bug exists by blocking direct login entirely for saml users. (Note: this will also fully disable webDAV access, as webdav does not support SAML login)

Blocking direct login is discussed in a few places currently, as direct login can also allow for 2FA bypass if the SAML idp enforces 2FA.

Allow native Nextcloud admins to still login · Issue #126 · nextcloud/user_saml · GitHub
and here:
[security] SSO with SAML: Locking down the direct login option - #10 by wwe

Seems like the current best option to disable direct login for LDAP backed users is to intentionally set the LDAP login UID to a non-existent LDAP attribute. @wwe suggests the below. This worked well for me:


To disable direct login for local nextcloud users that should only login using saml, that are not backed by ldap, just set all saml users that exist in the nextcloud database to random, long passwords that no one knows, this effectively blocks the user from using direct login and webdav; effectively enforces saml login only.

UPDATE: I’ve tested in a lab environment without LDAP backed users, just SAML mapping to an existing nextcloud user, the issue is the same. Any direct login corrupts all of that user’s auth tokens, which then prevents saml login.


— update: webdav client login seems to ‘corrupt’ an existing authtoken that was created via a saml login.

So if you delete all tokens, login via saml successfully, then login via a webdav client, it’ll corrupt the existing saml authtoken, and you wont be able to login via saml again.

Then for the ‘?direct=1’ nextcloud form login: if you delete all auth tokens, then login via the direct form, you wont be able to login via saml from that point on.

So webdav login seems to only corrupt an existing authtoken, while direct form login just creates a corrupt authtoken right away. Either way the corruption enters though, once in that state the only way to re-enable saml login is to delete the corrupted authtoken(s).

weird bug.

I updated my initial reply with further details on the corruption i notice, and a new ways to detect it and remove it from the oc_authtoken table for all users.

OMG Thank you so much taking the time sharing this informations. I have not yet 100% tested everything to make sure that my cases are all covered, because I currently lack the time to do so. But the initial tests have already shown very promising results and I can log in via SAML as expected.

Same here.

  • Upgraded to 26
  • Using SamlSSO with Authentik
  • Get 500 error

→ Disabled ‘Password Policy’ app and did the steps @peacepenguin suggested and it started to work again.

As @peacepenguin also pointed out, that error happens because of some toke-corruption when using WebDAV. Unfortunately I have several applications that need WebDAV, so for now I guess I have to remove/recreate my tokens every time my session expires.

I hope this bug will be fixed soon!

Cheers to the team and the community!!