Securing and Operating frp: Authentication, Policy, and Limits
A direct XTCP path can reduce dependence on the relay, but it does not answer the more basic governance questions around frp: who may register a client, who may create a proxy, who may reach the service, and what protects the bytes while they travel. This chapter separates those questions and connects them to frp’s authentication, TLS, mode-specific secrets, port limits, health controls, dynamic configuration, and server plugins. The result is a practical security model that distinguishes an identity check from confidentiality and a policy hook from an availability guarantee.
Four questions that should not be collapsed
A deployment becomes easier to reason about when its controls are assigned to four separate questions.
Who may register a client? This is the frpc-to-frps session question. A client must authenticate before its control relationship becomes a managed source of proxies and work connections. Token authentication and OIDC answer this question in different ways.
Who may create or change a proxy? This is the control-plane admission question. A client may be authenticated and still be constrained by server-side port rules, per-client limits, or an external policy plugin. The answer should not be inferred from the fact that a client can log in.
Who may reach the service? This is the data-plane audience question. A public TCP or HTTP listener, an HTTP authentication rule, an STCP visitor secret, and an XTCP allow-user rule create different audiences. A client that is allowed to register is not automatically the same as an Internet user who is allowed to reach every proxy that client owns.
Are the bytes protected in transit? This is the confidentiality and integrity question. TLS, the v2 control-channel AEAD negotiation, per-proxy encryption, and application-level HTTPS or authentication operate at different layers. A successful login proves an identity relationship; it does not by itself prove that every payload is confidential.
These questions often appear together in one configuration, which is why they are easy to confuse. A token can be required for client registration while the public web service still needs its own authentication. An STCP secret can restrict a visitor while the application still needs TLS. A TLS-protected control connection can coexist with a deliberately public HTTP proxy. The configuration is safer when each intended property has an explicit control rather than an assumed one.
Registration authentication is not payload confidentiality
In token mode, frp derives a timestamped authentication key from the configured token and the login timestamp. The server compares the presented value in constant time. Optional additional scopes can apply the same style of authentication to heartbeat messages and to new work connections, rather than limiting the check to the initial Login. This changes the strength of the session’s ongoing admission checks, but it does not change what a local application considers an authorized user.
The token implementation is also worth describing precisely. It is a time-varying comparison key derived from the token and timestamp; it is not a general password-storage scheme, and it is not a synonym for TLS or a modern authenticated encryption protocol. The source’s use of a timestamp and constant-time comparison helps answer whether a message matches the configured token at the expected time.