Acknowledgment
Is your feature request related to a problem?
Hi! Now that Fireshare supports multiple users, would you be open to a contribution that lets an external identity provider authenticate those users?
I’ve read #486 and understand the concerns about ongoing maintenance, reproducing authentication problems, and unsafe configurations. Before starting a fork or preparing a PR, I wanted to ask whether either of these approaches would be acceptable.
My use case is signing in through Authentik while retaining Fireshare’s own users, permissions and media ownership. I’m not looking to change anonymous sharing or require viewers to log in to open shared links.
Contribution and maintenance
I’d be willing to work on an implementation, automated tests, reproducible test-provider/proxy setup, and documentation—including configuration mistakes and recovery procedures.
Before doing that, I’d like to understand:
- Would either approach be welcome?
- Would you prefer native OIDC, a smaller trusted-proxy interface, or neither?
- What testing and ongoing maintenance expectations would you have for accepting it?
If external authentication remains outside the intended scope, that’s useful to know too. I’d rather establish that before putting a substantial PR in front of you.
Thanks for considering it!
Describe the solution you'd like
Option 1: Optional native OIDC
Fireshare handles the OIDC login flow using a maintained library, then establishes its existing application session.
A deliberately limited initial implementation could include:
- One configured OIDC provider, disabled by default.
- Authorization Code flow with PKCE and validated ID tokens.
- External identities mapped to local users by issuer and subject—not automatically linked by matching email or username.
- Explicit opt-in account creation with non-admin defaults.
- Existing local permissions and a local break-glass administrator retained.
- No initial group-to-admin mapping, automatic linking to existing accounts, or changes to public sharing.
This would provide a direct login experience, but does introduce provider integration code and its associated maintenance.
Describe alternatives you've considered
Option 2: Optional trusted-proxy authentication
Fireshare accepts a verified identity from a configured authentication proxy, such as OAuth2 Proxy or an Authentik proxy, and maps it to a local user. The proxy handles OIDC, MFA and provider-specific behavior outside Fireshare.
The application-side scope could be limited to:
- An explicitly enabled trusted-proxy mode.
- A documented identity-header contract using a stable identifier.
- Mapping that identity to a local user, retaining Fireshare’s permissions.
- Conservative account creation and no implicit administrator privileges.
- Fail-closed handling of missing or invalid identity information on protected operations.
This would not mean blindly trusting a header supplied by any client. The deployment would need to prevent direct access around the proxy, and the proxy would need to strip and replace incoming identity headers. The trust boundary and behavior for anonymous sharing would need to be clearly defined and tested.
This option would keep provider-specific integration outside Fireshare, although user mapping and authentication lifecycle behavior would still need application support.
Additional context
No response
Expectations
Acknowledgment
Is your feature request related to a problem?
Hi! Now that Fireshare supports multiple users, would you be open to a contribution that lets an external identity provider authenticate those users?
I’ve read #486 and understand the concerns about ongoing maintenance, reproducing authentication problems, and unsafe configurations. Before starting a fork or preparing a PR, I wanted to ask whether either of these approaches would be acceptable.
My use case is signing in through Authentik while retaining Fireshare’s own users, permissions and media ownership. I’m not looking to change anonymous sharing or require viewers to log in to open shared links.
Contribution and maintenance
I’d be willing to work on an implementation, automated tests, reproducible test-provider/proxy setup, and documentation—including configuration mistakes and recovery procedures.
Before doing that, I’d like to understand:
If external authentication remains outside the intended scope, that’s useful to know too. I’d rather establish that before putting a substantial PR in front of you.
Thanks for considering it!
Describe the solution you'd like
Option 1: Optional native OIDC
Fireshare handles the OIDC login flow using a maintained library, then establishes its existing application session.
A deliberately limited initial implementation could include:
This would provide a direct login experience, but does introduce provider integration code and its associated maintenance.
Describe alternatives you've considered
Option 2: Optional trusted-proxy authentication
Fireshare accepts a verified identity from a configured authentication proxy, such as OAuth2 Proxy or an Authentik proxy, and maps it to a local user. The proxy handles OIDC, MFA and provider-specific behavior outside Fireshare.
The application-side scope could be limited to:
This would not mean blindly trusting a header supplied by any client. The deployment would need to prevent direct access around the proxy, and the proxy would need to strip and replace incoming identity headers. The trust boundary and behavior for anonymous sharing would need to be clearly defined and tested.
This option would keep provider-specific integration outside Fireshare, although user mapping and authentication lifecycle behavior would still need application support.
Additional context
No response
Expectations