Comment by ta1243

My team self hosts multiple internal services, including vaultwarden.

For most of these we use our standard corporate OIDC provider to provide autentication and accounting, either onto a proxy or direct on the service, that passes the user through, the hosted service is either fine (just logs the user in its local access logs for the accounting part) because it's allowed for all our corporate users, or the service uses its own authorisation logic to allow or reject the users.

Some devices are just generic user/password on the device itself -- the authorisation there is that the group responsible for that device has to keep the credential secure. Any authenticated Corp user can access the login page, and that gets logged, but the authorisation is a simple user/password.

If the credential isn't secure (because people are terrible with security) then at least the attacker is logged, and has had to authorise access.

Some authentication is better. Our guacamole hosts for example are authenticated on proxy with OIDC, then passed through to the guacamole server which does its own authorisation based on its internal database (which itself is managed via a github approach - to add joe.bloggs@corp.com to the "Washington Servers" group you add his identity to the right part of the "groups.conf" file and when the PR is merged it applies across the estate within a minute or two). Then they can access all connections in "Washington", but "davey.jones@corp.com" isn't in that group, so can't.

Likewise our IPAM will create a user in the "readonly" group automatically (our policy is ip records are available to everyone in the company), but they then need moving into an elevated rights using IPAM tooling to allocate IP addresses.

Vaultwarden though we maintain separate user and password, we still have the OIDC front end, but it's completely ignored for another layer of authorisation. I'm about to go on leave so I won't be thinking too much about if this will help, but its good to have the option.