[GH-ISSUE #5275] [Feature Request] pluggable per-proxy authentication

gitea-mirror commented

2026-05-05 14:34:54 -06:00

Owner

Originally created by @fred01 on GitHub (Apr 1, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5275

Describe the feature request

Hi! Currently HTTP proxies support Basic Auth via httpUser/httpPassword, which works well. But it would be nice to have the option to use other authentication methods on a per-proxy basis — for example, validating a Bearer token, checking a custom header, or delegating the decision to an external service.

Would you be open to the idea of making per-proxy authentication pluggable? The concept would be similar to how server plugins work today (external HTTP services called on lifecycle events like Login,NewProxy), but applied at the request level — frps would call an auth plugin before forwarding each HTTP request to the tunnel.

To give a rough idea of what the config could look like (not a concrete proposal, just thinking out loud):

  [[proxies]]
  name = "my-service"
  type = "http"
  localPort = 8080
  customDomains = ["my-service.example.com"]

  [proxies.auth]
  type = "plugin"  # "basic" | "plugin" | "header" | ...

  [proxies.auth.plugin]
  type = "http"  # "http" | "exec" | "builtin" | ...
  addr = "http://127.0.0.1:9090/verify"

  [proxies.auth.plugin.metadata]
  # arbitrary key-value pairs passed to the plugin on each request

Basic Auth would remain the default and work exactly as it does today. The plugin approach would be opt-in.

If you're generally open to this direction, I'd be happy to write up a more detailed proposal and discuss it here before submitting a PR.

Describe alternatives you've considered

No response

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @fred01 on GitHub (Apr 1, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5275 ### Describe the feature request Hi! Currently HTTP proxies support Basic Auth via httpUser/httpPassword, which works well. But it would be nice to have the option to use other authentication methods on a per-proxy basis — for example, validating a Bearer token, checking a custom header, or delegating the decision to an external service. Would you be open to the idea of making per-proxy authentication pluggable? The concept would be similar to how server plugins work today (external HTTP services called on lifecycle events like Login,NewProxy), but applied at the request level — frps would call an auth plugin before forwarding each HTTP request to the tunnel. To give a rough idea of what the config could look like (not a concrete proposal, just thinking out loud): ``` [[proxies]] name = "my-service" type = "http" localPort = 8080 customDomains = ["my-service.example.com"] [proxies.auth] type = "plugin" # "basic" | "plugin" | "header" | ... [proxies.auth.plugin] type = "http" # "http" | "exec" | "builtin" | ... addr = "http://127.0.0.1:9090/verify" [proxies.auth.plugin.metadata] # arbitrary key-value pairs passed to the plugin on each request ``` Basic Auth would remain the default and work exactly as it does today. The plugin approach would be opt-in. If you're generally open to this direction, I'd be happy to write up a more detailed proposal and discuss it here before submitting a PR. ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [x] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [x] Server Plugin - [x] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 14:34:55 -06:00

gitea-mirror commented

2026-05-05 14:34:57 -06:00

Author

Owner

@fatedier commented on GitHub (Apr 1, 2026):

We currently don't plan to introduce more complex Layer 7 features within the existing architecture. Supporting such functionality requires a more well-designed architecture, which we'll consider after a future overall refactoring.

@fatedier commented on GitHub (Apr 1, 2026): We currently don't plan to introduce more complex Layer 7 features within the existing architecture. Supporting such functionality requires a more well-designed architecture, which we'll consider after a future overall refactoring.

gitea-mirror commented

2026-05-05 14:34:58 -06:00

Author

Owner

@fred01 commented on GitHub (Apr 1, 2026):

Thanks for the quick response! Totally understand. Will keep an eye on the project for when the refactoring happens.

@fred01 commented on GitHub (Apr 1, 2026): Thanks for the quick response! Totally understand. Will keep an eye on the project for when the refactoring happens.