OIDC group header forward for account controls

[JDB321Sailor]

I appreciate everything you have done with your fork of the original filebrowser.

Is your feature request related to a problem? Please describe. When a user authenticates via Oauth from the provider and is redirected back, a user is created if one doesn't exists. There is no option to turn create users off for OIDC, so a new user is created if they authenticate. Additionally there is no look at the group header to identify if the user should be a standard user or admin.

Describe the solution you'd like Three additional options in the config.yaml for OIDC. 1. Control creating users. 2. Allow for group header for admin account from the authentication provider. 3. Allow for a group header to control access.

Describe alternatives you've considered you would have to manually assign the admin role after account creation. In a deployment environment, the ability to control filebrowser access and control level from the authentication provider would be a nice to have.

Additional context The inclusion of an OAuth function has been a requested feature on the old filebrowser for years with no action. You have made possible one of the most requested features, and still in BETA!! Thanks again for the time you have put into this awesome project!!

[gtsteffaniak]

Can you help explain the scenario/purpose for authenticating with oidc but not automatically creating a user?

You want only manually created users to work with oidc?

[JDB321Sailor]

The reason someone might want to prevent automatically creating a user is to prevent a user created within authentik from having access into filebrowser if they were to input the filebrowser URL. If no group header check is done, like it does now, all users I have created in authentik will be auto created an account in Filebrowser and I have now way to prevent them from gaining access. There are two methods that I can imagine to be used to control access to filebrowser with Oauth. Prevent all user creation and then verify users against the current list of users for authentication. The second, is use a group header to verify the user should have access and at what level. With the group header check, then the system should create the user and with admin (or equivalent) group header can be used to grant admin privilege.

[gtsteffaniak]

ok thanks for the explanation, I could add both configurations.

• a config to enable/disable automatic creation
• a config to only authorize oidc with a specific group header.

[gtsteffaniak]

added 2 of 3 features in a quick 0.7.8 release that also fixed a big bug in 0.7.7 blocking oidc logins.

As for the third feature - 3. Allow for a group header to control access.

you mean a group setting for every permission option available?

• admin (Done)
• share
• api
• modify

Ability to control each of the other permission access ?

[baur]

How to set admin group?

    oidc:
      enabled: true
      clientId: "filebrowser-client"
      clientSecret: "***"
      issuerUrl: http://localhost:4000
      scopes: "openid profile email"
      createUser: true
      adminGroup: "admins"

2025-06-10T03:55:23.309Z [info]: Userinfo response (/me'): 
{
  "sub": "User1",
  "name": "User1 User1",
  "username": "User1",
  "preferred_username": "User1",
  "group": "admins",
  "email": "[email protected]"
}

[cyndane31]

I can confirm the adminGroup setting does not seem to be working.

It would be nice to be able to configure groups with set permissions & scopes for various shares. Alternatively, being able to setup a custom scope on the provider that specifies granular permissions for that specific user.

Something like this:

"fbq_perms": {
  "admin": false,
  "modify": true,
  "share": false,
  "api": true,
  "sources": {
    "source1": "/",
    "source2": "subfolder",
}

with an unspecified source being no access of course :)

[gtsteffaniak]

What oidc provider do you use? Groups is expected to be an array, so it makes sense what you have wouldn't work:

2025-06-10T03:55:23.309Z [info]: Userinfo response (/me'): { "sub": "User1", "name": "User1 User1", "username": "User1", "preferred_username": "User1", "groups": ["admins"] "email": "[email protected]" }

The above would work. I checked the oidc spec and groups as an array looked to be the standard.

[baur]

✅ resolved — thank you!

Is it possible for users from the "admin" group to override certain settings - for example:

userDefaults:
  disableSettings: true

User1 is part of the admin group, but can't open the config:

What oidc provider do you use?

It's a custom OIDC provider built with Node.js — so I have full control over the structure

[JDB321Sailor]

added 2 of 3 features in a quick 0.7.8 release that also fixed a big bug in 0.7.7 blocking oidc logins.

As for the third feature - 3. Allow for a group header to control access.

you mean a group setting for every permission option available?

admin (Done)
share
api
modify

Ability to control each of the other permission access ? (Group header names could be chosen arbitrarily but named for simplicity) My OIDC provider is Authentik for the example below. I would want:

1. Filebrowser to conduct a group header check prior to auto account creation. This feature would allow for access control into Filebrowser by having a group in Authentik that gets filebrowser access. A working example, a user is created in Authentic, assigned no groups, and attempts to Oauth at filebrowser.example.com, they get denied access and no account created. User in Authentik is added to filebrowser group in Authentic, then they Oauth Filebrowser successfully and have an account created with access to default share, or a username directory.
2. An additional feature that would be a nice to have: using the group header to configure which additional shares the user gets access to by default and custom group configuration. An example: user in Authentik is added to Filebrowser & Superuser group, they get access to filebrowser and get the default share or a username directory and Superuser additional shares that can be configured.
3. Final group header would be the admin group that you have implemented, allowing the user admin access.
4. I can't think of a reason to use Oauth for access into the API or what that would look like.
5. Final thoughts, I could see using the group header , like supersuser, to allow the user additional r/w and delete access to a specific drive while Filebrowser default user could read but not write or delete.

[TheDarkula]

I am not certain if this fits in this issue, but for the adminGroup, is it possible to have a nested structure like clientRole.admins?

Comparing this to Open WebUI They have these two environment variables:

OAUTH_ADMIN_ROLES
OAUTH_ROLES_CLAIM

Either way would suffice :)

[Itay080]

Hi adminGroup still does not seem to be working for me My user groups output looks like this

    "groups": [
        "filebrowser",
        "paperless",
        "authentik Admins"
    ]

adminGroup is set to "authentik Admins" but my user is not being granted admin privileges

This is what I see in the logs with debug logging enabled

filebrowser  | 2025/06/12 11:29:56 [DEBUG] oidc.go:136: ID Token verified and claims decoded: map[acr:goauthentik.io/providers/oauth2/default amr:[pwd mfa] aud:redacted auth_time:1.749724378e+09 email:[email protected] email_verified:true exp:1.749728096e+09 given_name: groups:[filebrowser paperless authentik Admins] iat:1.749727796e+09 iss:https://auth.redacted.one/application/o/filebrowser/ name: nickname:itay_admin preferred_username:itay_admin sid:d0fe87b925a7be352e0c21c1d1b5f5ddd3c260d57741e67420180b58c8da15ac sub:8bbba26768f2a1cc22801de6c77565d9d76f4319a2dcd59e402e3a4c24920070]
filebrowser  | 2025/06/12 11:29:56 [DEBUG] oidc.go:226: Successfully authenticated OIDC username: [email protected] isAdmin: false

[gtsteffaniak]

I think I know why there's one small tweak I need to make.

It currently only applies to new users that get first created on login.

I need to update it to "update" current users to add admin permission based on the group each time they login.

[Itay080]

I think I know why there's one small tweak I need to make.

It currently only applies to new users that get first created on login.

I need to update it to "update" current users to add admin permission based on the group each time they login.

It seems to not work for me at all for some reason 😅 Even if I delete the database and log in for the first time, Filebrowser doesn't identify the user as an admin and as you can see in the logs I even tried removing the user from all the other groups

filebrowser-a  | 2025/06/12 11:57:10 [DEBUG] oidc.go:136: ID Token verified and claims decoded: map[acr:goauthentik.io/providers/oauth2/default amr:[pwd mfa] aud:redacted auth_time:1.749724378e+09 email:[email protected] email_verified:true exp:1.749729729e+09 given_name: groups:[authentik Admins] iat:1.749729429e+09 iss:https://auth.redacted.one/application/o/filebrowser/ name: nickname:itay_admin preferred_username:itay_admin sid:d0fe87b925a7be352e0c21c1d1b5f5ddd3c260d57741e67420180b58c8da15ac sub:8bbba26768f2a1cc22801de6c77565d9d76f4319a2dcd59e402e3a4c24920070]

filebrowser-a  | 2025/06/12 11:57:10 [DEBUG] oidc.go:226: Successfully authenticated OIDC username: [email protected] isAdmin: false
filebrowser-a  | 2025/06/12 11:57:10 [DEBUG] storage.go:126: Creating user: [email protected] []
filebrowser-a  | 2025/06/12 11:57:10 [DEBUG] users.go:156: Saving user [[email protected]] changepass: true

[gtsteffaniak]

Oh, I know why. it's only applying after the user info endpoint which only applies as fallback.

Meaning oidc services like authelia dont work but authentik and others do.

[QuiGonLeong]

I've deleted my user account in filebrowser and then tried logging in using authentik oidc and it still doesn't create my user as an admin

createUser: true # create user if it does not exist adminGroup: "authentik Admins" # if set, users in this group will be granted admin privileges.

[robflate]

Also doesn't work for me using Authentik on a fresh database;

"groups": [
    "authentik Admins",
    "authentik Users",
    "authentik Limited"
    ]

oidc:
    ...
    adminGroup: "authentik Admins"

Worth noting that if I add;

permissions:
    admin: true

it correctly sets the Authentik user as admin.

[gtsteffaniak]

if you're using authentik can you check the preview for your provider. here is my example

Groups exists and has the group for your user?

[robflate]

config.yml auth section;

auth:
  methods:
    password:
      enabled: false
    oidc:
      enabled: true
      clientId: "xxxx"
      clientSecret: "xxxx"
      issuerUrl: "https://authentik.xxxx.com/application/o/filebrowser-quantum/"
      scopes: "email openid profile"
      userIdentifier: "username"
      disableVerifyTLS: false
      logoutRedirectUrl: "https://authentik.xxxx.com/application/o/filebrowser-quantum/end-session/"
      createUser: true
      adminGroup: "authentik Admins"   

[gtsteffaniak]

Figured this out regarding group based admin access and updated 0.7.9 with a fix.

If using docker , do a docker pull gtstef/filebrowser to get the recent changes and try again

[QuiGonLeong]

Working correctly for me now

2025/06/15 14:49:51 [DEBUG] oidc.go:197: User xxxxx is in admin group authentik Admins, granting admin privileges. 2025/06/15 14:49:51 [DEBUG] oidc.go:209: Successfully authenticated OIDC username: xxxxx isAdmin: true 2025/06/15 14:49:51 [DEBUG] storage.go:126: Creating user: xxxxx [] 2025/06/15 14:49:51 [DEBUG] users.go:156: Saving user [xxxxx] changepass: true

[QuiGonLeong]

Running into an issue where only users in the 'authentik admins' group can log in. Users in other groups get permission denied from Authentik.

I've confirmed that user/group is bound correctly in Authentik. I'm not seeing the auth request hitting Filebrowser since it's getting denied by Authentik. This user/group is able to OAuth to other configured apps.

[TheDarkula]

@gtsteffaniak This may have been lost in the shuffle: https://github.com/gtsteffaniak/filebrowser/issues/685#issuecomment-2964594888 :)

Essentially, my roles structure looks like this: client-groups.filebrowser-groups.admins.

From what I can tell from looking at debug logs, it is hard-coded to look for scopes.groups.admins, where scopes is coming from the config.yaml.

Is there an override where I can replace groups like Open WebUI have with OAUTH_ROLES_CLAIM?

[robflate]

The updated 0.7.9 image is working for me too;

2025/06/15 19:45:31 [DEBUG] oidc.go:197: User authentik is in admin group authentik Admins, granting admin privileges.
2025/06/15 19:45:31 [DEBUG] oidc.go:209: Successfully authenticated OIDC username: authentik isAdmin: true
2025/06/15 19:45:31 [DEBUG] storage.go:126: Creating user: authentik []
2025/06/15 19:45:31 [DEBUG] users.go:156: Saving user [authentik] changepass: true

However, a default admin user is also created. I'm sure that wasn't the case previously when oidc auth was enabled and password auth was disabled?

You said here that you currently cannot delete the default admin user. Can you confirm that with password auth disabled there is no way that the default admin user can login?

[gtsteffaniak]

@TheDarkula yeah its hard for me to parse the context on this thread, I think its best to open a new issue with your details. I think this one is a bit too broad. The remaining feature here is to allow granting sources based on OIDC groups -- this is a great idea.

I will open a new story for that feature and close this one. Any other issues or features should also get their own issue.