mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #4989] auth.token used for encryption in addition to authentication? #3932
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#3932
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @caphrim007 on GitHub (Sep 20, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4989
Bug Description
I started using frpc/s with token authentication. My configuration looked like the following (in both)
I later switched to OIDC authentication but left the token stuff in there because I thought that FRP would treat these parameters conditionally. In other words, my updated config looked like this
frps
and
frpc
The behavior I expected to see was that FRPc/s would ignore the
auth.tokenvalues.Instead, what I saw was what appeared to be an infinite loop of LoginInfos and clients closing connections.
When I looked deeper, I think what is occurring is that FRP uses auth.token for more than simply authentication.
The server encounters this code
https://github.com/fatedier/frp/blob/dev/server/control.go#L188
The value of
ctlConnEncryptedcomes from here I thinkhttps://github.com/fatedier/frp/blob/dev/server/service.go#L595
which sets it to
!internal.The value of
internaldiffers based on the Listener being handled. The Listeners I have areand, I assume, this default one here
FRPc has similar connection encrypted logic here
My grok'ing of that handler setup is "internal is false, but
!internalmakes it true, ergoctlConnEncryptedis true, ergo use encryption.".When I looked into the docs on useEncryption, I dont see any mention of auth.token needing to be required. I do see this here
which says
Which seems to imply that
auth.tokenis used. So my leaving it in the frps.toml and was inadvertently making the server use it.When I removed auth.token from either the frps.toml or frpc.toml (keeping it in the other), the behavior I mentioned of "infinite loop of re-logins and close connection" happened.
When I removed auth.token from both frpc.toml and frps.toml, I connected with OIDC as I expected.
Is this intended behavior?
I didn't see documentation specifying usage of the auth.token here
So I was surprised to find in the code its apparent re-usage outside of authentication.
What I have not tried doing yet is setting
transport.useEncryption = truein the frpc.toml file's proxies. I suspect this might cause the client to now use the auth.token that I had kept in there, and since the server would be using it to begin with (by virtue of!internal) that the connection would now complete.frpc Version
0.63.0
frps Version
0.63.0
System Architecture
linux/amd64
Configurations
frpc.toml
frps.toml
Logs
when the auth.token is set, the client logs will just spin emitting this sequence of messages
I think the
message type erroris related to the client being unable to decrypt the encrypted message being sent from the server.Steps to reproduce
...
Affected area
@fatedier commented on GitHub (Sep 21, 2025):
This is the expected behavior. auth.token must always be consistent between frps and frpc. When you switch to another authentication method, you can set this parameter to an empty value to avoid conflicts.
@caphrim007 commented on GitHub (Sep 22, 2025):
@fatedier thanks for the clarification. Would you accept a (docs) PR that clarifies the usage of the auth.token value (if it is set in the client or server) under the section here https://github.com/fatedier/frp?tab=readme-ov-file#encryption-and-compression ?
@fatedier commented on GitHub (Sep 22, 2025):
In fact, since frpc and frps mainly rely on TLS for encrypted transmission, transport.useEncryption is no longer recommended. For now, the documentation does not intend to provide more detailed explanations.
@caphrim007 commented on GitHub (Sep 22, 2025):
ok. understood. thanks for the feedback