token in NewWorkConn doesn't match token from configuration

Error message

token in NewWorkConn doesn't match token from configuration

What it means

Same constant-time static-token check applied to NewWorkConn messages, only when 'NewWorkConns' is in the additional auth scopes. frps computes md5(token + newWorkConn.Timestamp) and compares it to newWorkConn.PrivilegeKey; a mismatch aborts the new work connection.

Source

Thrown at pkg/auth/token.go:88

func (auth *TokenAuthSetterVerifier) VerifyPing(m *msg.Ping) error {
	if !slices.Contains(auth.additionalAuthScopes, v1.AuthScopeHeartBeats) {
		return nil
	}

	if !util.ConstantTimeEqString(util.GetAuthKey(auth.token, m.Timestamp), m.PrivilegeKey) {
		return fmt.Errorf("token in heartbeat doesn't match token from configuration")
	}
	return nil
}

func (auth *TokenAuthSetterVerifier) VerifyNewWorkConn(m *msg.NewWorkConn) error {
	if !slices.Contains(auth.additionalAuthScopes, v1.AuthScopeNewWorkConns) {
		return nil
	}

	if !util.ConstantTimeEqString(util.GetAuthKey(auth.token, m.Timestamp), m.PrivilegeKey) {
		return fmt.Errorf("token in NewWorkConn doesn't match token from configuration")
	}
	return nil
}

View on GitHub (pinned to 6c8a8d0a97)

Solutions

Mirror authentication.additionalScopes with NewWorkConns on frpc so it signs NewWorkConn messages
Ensure authentication.token matches exactly on frps and every frpc/visitor
For custom clients, set NewWorkConn.PrivilegeKey = md5(token || timestamp) when the scope is enabled
Restart all peers after scope or token changes

Example fix

# before — only frps requires NewWorkConn auth
# frps.toml
authentication.additionalAuthScopes = ["NewWorkConns"]

# after — frpc signs NewWorkConn too
# frpc.toml
authentication.additionalAuthScopes = ["NewWorkConns"]

Defensive patterns

Strategy: validation

Validate before calling

expected := md5hex(authToken + strconv.FormatInt(newWorkConn.Timestamp, 10))
if expected != newWorkConn.PrivilegeKey {
    return errors.New("NewWorkConn auth failed; token or scope mismatch")
}

Prevention

Include NewWorkConns in additionalAuthScopes on both frps and frpc/visitor
Custom visitors must set NewWorkConn.PrivilegeKey = md5(token||timestamp)
Test with one work connection after enabling the scope

When it happens

Trigger: NewWorkConns scope enabled and a work-connection request carries a PrivilegeKey derived from a different token — e.g. only one side has the scope enabled, a custom visitor implementation skips signing NewWorkConn, or the token differs between frps and the visiting frpc.

Common situations: Hardening configs by adding NewWorkConns to additionalAuthScopes on frps while frpc (or a custom visitor) still sends unsigned NewWorkConn messages; token drift between environments after a rotation.

Related errors

AI-assisted analysis of fatedier/frp@6c8a8d0a97 (2026-08-15). Data as JSON: /api/errors/edca644c5bee1170. Report an issue: GitHub.