Added OIDC Login

[BaseCrusher]

This PR adds the option to use OIDC as a login method.

I made sure, that the old configuration is still usable but marked it as deprecated as there needed to be some minor changes in order to get OIDC working with the current auth schema.

I also added a docker-compose with a Dockerfile build and KeyCloak configuration to test if the OIDC login locally.

If there is anything missing or you wish for adjustments of changes let me know.

Implements: #1123

[CLAassistant]

All committers have signed the CLA.

[SystemZ]

Tested this against authentik (2026.x) — works without any code changes. Built the branch as-is, configured an authentik OAuth2/OIDC provider (openid email profile scopes, authorization_code + refresh_token grants), set issuer/clientId/clientSecret in backrest, and login + callback + session all work. Running behind a reverse proxy that terminates TLS, I set oidc.redirectUrl explicitly so the callback URL stays https:// (the X-Forwarded-Proto handling looks correct too). Email claim mapping works fine. 👍

Two small unrelated nits in the local test harness: scripts/keycloak/docker-compose.yml points dockerfile: Dockerfile.build with context: ../.., which resolves to the repo root rather than scripts/keycloak/Dockerfile.build; and the committed webui/pnpm-workspace.yaml has placeholder allowBuilds values that break a plain pnpm install (the Dockerfile rewrites them, so it only bites outside Docker).

[BaseCrusher]

@SystemZ You're right those were some small errors that happened while cleaning up the branch. I have fixed those. 🙂

[garethgeorge]

HI, thanks for the interest in contributing this! Generally open to merging an OIDC implementation, but one item I want to discuss / callout is that backrest does not have a finegrained permission model today which I expect would make this more useful.

I'm curious to hear a bit about the use case you're looking at for native OIDC vs an authenticating reverse proxy infront of backrest? The cost of adding something like this is it makes the auth layer more complicated to audit, I want it to stay simple and secure for users whos' primary threat model is accidentally exposing backrest on the web.

In a first review pass though, initial implementation direction generally looks good. I'll leave a bit of high level feedback and will try to do a deeper review pass next weekend.

[BaseCrusher]

Hello @garethgeorge

I do completely agree that having a permission model that is more fine-grained than the current implementation would be beneficial. This being said, the permission model can be added either way. I personally would not advise that there should be a mapping from OIDC claims to the app's permission system, if that was what you were trying to hint at. Other than that, I would think that with local and generic OIDC auth there should not be any changes to the auth system for the foreseeable future, as this pretty much covers 99% of the use cases for login options.

The main use case for me is that I am hosting all of my apps myself and I want to have a single source of truth for logins, so the implementation itself was more out of self-interest. :D

Of course, I do get the point that this makes the auth model a bit more complicated, though I tried to keep it at a minimum. That said, there are some changes that I made which I would consider not optimal, but this was so that I would not create a huge PR. For example, the frontend needs to be aware of some OIDC settings, so I had to implement an endpoint for that, and it leads to the UI querying the backend in order to know how some elements should be rendered. A better implementation would be to have the frontend rendered depending on the configuration, but this would blow this PR out of scope.

Maybe also a quick word on the configuration. I currently wrote it without the use of migration to make it fully compatible with the older configuration version. If the migration is desired, I would add it instead.

Apologies for the long response. Some of this should have been in the PR's main post. I usually don't do a lot of GitHub contributions.