Google auth: “Map Groups” blocks every login — Cloud Identity rejects the labels filter in searchDirectGroups (400 INVALID_ARGUMENT)

[whatwho]

Version

Wiki.js 3.3.0 (ghcr.io/requarks/wiki:3.3.0), Docker, behind a reverse proxy.

Summary

With Map Groups enabled on a Google authentication strategy, every Google login fails with ERR_PROVIDER_REQUEST_FAILED. The group lookup fails closed, which is the right default, but it means nobody can sign in while Map Groups is on.

The cause is the query sent to groups.memberships.searchDirectGroups. Google rejects the labels clause for this Workspace, even though its documentation says a label is required.

Steps to reproduce

1. Google Workspace domain, internal OAuth client, Cloud Identity API enabled in the client's project.
2. Google strategy with Restrict to Workspace Domain set, Map Groups on, Match Groups By: Group address.
3. Sign in with a Workspace account that is a direct member of one or more Google Groups.

Actual result

The login fails with auth.errors.loginError / error.ERR_PROVIDER_REQUEST_FAILED. With Auth Debug on:

[AUTH] google strategy <id>: asking the Cloud Identity API for group memberships: member_key_id == 'user@example.org' && 'cloudidentity.googleapis.com/groups.discussion_forum' in labels
warn: Google strategy <id> asked the Cloud Identity API for group memberships and it answered 400.
[AUTH] google strategy <id>: the Cloud Identity API answered 400: {
  "error": { "code": 400, "message": "Request contains an invalid argument.", "status": "INVALID_ARGUMENT" }
}

Expected result

The user's Google Groups are read and mapped to wiki groups of the same name.

Reproduced outside Wiki.js (Google API Explorer, same user)

Method	Query	Result
groups.memberships.searchDirectGroups (parent: groups/-)	member_key_id == 'user@example.org' && 'cloudidentity.googleapis.com/groups.discussion_forum' in labels	❌ 400 INVALID_ARGUMENT (with and without pageSize)
groups.memberships.searchDirectGroups (parent: groups/-)	member_key_id == 'user@example.org'	✅ returns the user's groups
groups.search	parent == 'customers/<customer id>' && 'cloudidentity.googleapis.com/groups.discussion_forum' in labels	✅ returns the domain's groups

So the API, the OAuth scope and the user's permissions are fine. Only the labels clause in searchDirectGroups is rejected.

Where

backend/modules/authentication/google/authentication.ts, groupsFor(), line 158 in 3.3.0:

const query = `member_key_id == '${member}' && '${DISCUSSION_FORUM_LABEL}' in labels`

Suggested fix

Query with member_key_id == '<email>' only, and keep the Google-Groups-only behaviour by filtering client-side on each returned MembershipRelation's labels map (key cloudidentity.googleapis.com/groups.discussion_forum). If you'd rather not change behaviour for Workspaces where the labelled query works, retry without the label on a 400 instead.

Workaround

None without patching the image. Turning Map Groups off restores login, but group membership then has to be maintained by hand.

[NGPixel]

Can you try again with image 3.3.0-dev.750f664 with the "Auth Debug" flag enabled? If the mapping still doesn't work, please share the log entries which should have more info now.

[whatwho]

Thanks, 3.3.0-dev.750f664 fixes it! 🙏 With Map Groups on (match by group email, unassign missing groups), Google login succeeds and the user is put in the matching Wiki.js group. Removing the Google group membership removes the Wiki.js group on the next login.

One more thing I noticed: users created by SCIM don’t get any of the default Wiki.js groups. They aren’t added to the Users group, and the Google strategy’s “Assign to group(s)” setting doesn’t apply to them either (that setting is only shown when Registration is on, and Registration is off in our setup because SCIM creates the accounts).

Group mapping on Google login doesn’t fill this in. It adds the groups Google reports, but it never adds Users or the “Assign to group(s)” groups to an account that doesn’t already have them.

Would it be possible to either:

• add SCIM-created users to the Users group when they are created, or
• add Users and the strategy’s “Assign to group(s)” groups on the user’s first Google login?