pfSense API package authentication mode token lifetime and revocation differ by version
0 reputation · 15 Nov 2022, 12:45 UTC
0 reputation · 15 Nov 2022, 12:45 UTC
The integration must standardize on a single authentication mode for the community pfSense API package so that token handling, refresh logic, and revocation behavior are predictable in production.
The package exposes three auth modes — API token, JWT, and local credentials — but token lifetime, revocation semantics, and header formats shift between package releases. Lab validation on pfSense Community Edition may not reflect behavior on pfSense Plus, and the package is not covered by Netgate support.
Which authentication mode provides the most stable token lifetime and revocation semantics across pfSense API package versions? Does the selected mode behave consistently between pfSense CE and pfSense Plus when the same package version is installed? How should the client handle token refresh or re-authentication when the package is upgraded?
Use the local credentials authentication mode with a dedicated, least‑privilege pfSense user.
API‑token mode stores a bearer token whose field names, header format, expiry handling and server‑side revocation tables have changed across package releases, making lifetime and revocation unpredictable. JWT mode is stateless; revocation before expiry relies on a version‑specific blacklist that may not exist, so its semantics are also unstable.
page-all or specific ACLs).Authorization: Basic <base64(user:pass)> or session cookie).Does your security policy allow storing or transmitting a local pfSense user password (or its base64‑encoded form) in automation? If the answer is no, the recommendation shifts to API‑token mode – you would then need to pin the package version, capture the exact token header and expiry, and verify revocation on the target build.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.