[Bug] Custom OAuth scopes ignored

[Doridian]

Providers such as Kanidm require to present the scopes you want during the initial exchange. In this case, the groups or groups_name scope.

On the server, you can configure oauth2.scopes, but this has no effect on the frontend when it does the initial auth request. The default scopes are used.

[vincelegithub]

I was wondering why I wasn't able to assign roles in my instance with PocketID. Now I know the "groups" scope is not used, even if specified in the config file. So if anyone is wondering why they have no admins or managers when using PocketID for authentification, this is why. I hope this pull request is integrated soon. :)

[tatezach]

Confirming this with Authelia as the provider, and adding a consequence that makes it more than a configuration annoyance.

Same mechanism as described: the scope parameter is hardcoded in LoginView.jsx in both the web and the native (Capacitor) branch, and the frontend only receives client_id, auth_url and name from the config endpoint. So oauth2.scopes in selfhosted.yaml never reaches the authorization request.

Why this locks out administrators in single-circle mode. The OIDC group-based role mapping added in v0.1.76 (oauth2.admin_groups / oauth2.manager_groups) resolves the role from the groups claim in the userinfo response. Authelia only returns that claim if the groups scope was granted, so with the hardcoded scope the claim is always absent.

With single_circle_instance: true this is not recoverable through configuration. New OIDC users default to member, and personal-circle creation — the path that would otherwise grant admin — is skipped. The result is a fresh instance where the intended administrator is a plain member, and there is no admin anywhere who could promote them.

The role sync actively overwrites a manually repaired role, which makes the only workaround useless. This is the part I would like to add to the report, because it turns a configuration gap into a hard lockout. Reproduced on v0.1.79:

1. Role is member.
2. UPDATE user_circles SET role='admin', is_active=1 WHERE user_id=1 AND circle_id=1; — role is correctly admin.
3. Log out, log in via Authelia — role is back to member.

Verified that this is not a duplicate row in user_circles and not a stale database file: there is exactly one row for the pair, and the second OIDC user appears in the same file. The login genuinely writes the role back.

The mechanism appears to be that having admin_groups or manager_groups configured is by itself enough to treat the mapping as active, independently of whether any groups were actually received. With an empty group list the resolution then yields member, and the sync writes that on every login. So the presence of the config keys is worse than their absence: without them the sync returns before touching the database and a manually set role survives.

Confirmed workaround: comment out admin_groups and manager_groups, restart, then apply the SQL update. The role is then stable across logins. The groups scope on the Authelia client and the group memberships in users_database.yml can stay in place.

If that reading of the resolution logic is correct, it might be worth treating "mapping configured but no groups received" as inactive rather than resolving to member. That would keep the sync from degrading users when the claim is missing for any reason — misconfigured provider, revoked consent, or this scope bug.

Diagnosability. This is hard to identify from logs. Debug output shows a successful code exchange, a successful user lookup by email and a session insert, but no OIDC role sync line — because that line only appears when resolved and current role differ, and after the first downgrade they match again. So the write that caused the problem is invisible on subsequent logins. A debug line whenever the mapping is configured, including the received group list and the resolved role, would have saved a lot of time here.

Documentation gaps that compound this. config/selfhosted.yaml does not document scopes under oauth2 at all, even though the field exists in config.OAuth2Config and has no default value. The Authelia integration guide listed in Authelia documentation also lists only openid profile email, which is understandable since it was tested against v0.1.53, before role mapping existed. Its .env example additionally uses DT_OAUTH2_SCOPE and DT_OAUTH2_INFO_URL, which do not match the struct keys scopes and user_info_url and therefore have no effect. Once #162 and donetick#734 land, it would be worth adding a scopes block to the template with a note that groups is required for admin_groups / manager_groups.

Happy to test a build of #162 + donetick#734 against Authelia if that helps move the backend PR along.

EDIT, after digging a little deeper I found a few more details, I edited everything above.