Known limitations
PassBeyond is intentionally small and transparent. The following limitations are consequences of that design and should be evaluated for every protected application.
Sessions are stateless bearer tokens
The application session is a signed JWT cookie. It is not bound to a device and there is no server-side session database or individual revocation mechanism. A copied token can be replayed until it expires.
Visiting /saml/slo removes cookies in the current browser but cannot invalidate another copy of the JWT. Rotating the per-instance JWT secret invalidates all sessions at once.
IdP changes are delayed
User attributes and groups are copied into the JWT at authentication time. Changes at the IdP are not visible until the token expires and the user authenticates again. Disabling or deleting an IdP account does not terminate an existing PassBeyond session.
Use a session timeout that matches the organization's offboarding and privilege-change requirements.
One domain and backend per instance
An instance builds its URLs and cookie scope from one domain and proxies to one targetURL. Multiple services require multiple processes, listeners, configuration files, and dynamic state files.
Browser redirect flow
PassBeyond is designed primarily for browser-based applications. Mobile apps, native clients, command-line programs, and synchronization clients may not follow the SAML redirect and cookie flow correctly.
Some tested products therefore work in a browser but not through their mobile app or sync client. A passthrough token can support controlled automation, but it bypasses SAML and changes the security model.
Header-based backend identity
The backend learns identity through HTTP headers. This is safe only when the backend cannot be reached directly and trusts those headers exclusively from PassBeyond. PassBeyond does not configure the backend's authorization policy.
Applications that ignore the documented headers or require a different authentication protocol need additional integration.
No administration interface
There is no web UI for configuration, sessions, users, or health. Configuration is file- or environment-based; operation relies on process status, logs, protocol endpoints, and end-to-end login checks.
Local dynamic state
Generated secrets, the SAML key pair, and cached metadata live in one local JSON file. PassBeyond does not distribute or coordinate this state across replicas. Independently started replicas would generate different session secrets unless state is deliberately shared, and concurrent writes to one file are not a documented clustering mechanism.
Metadata behavior differs by source
Remote IdP metadata is cached and refreshed every 30 minutes. Local metadata is read only at startup. Neither mode replaces a planned process for IdP signing-certificate changes, validation, and rollback.
Path bypass uses prefix matching
passthroughPaths matches the beginning of the request path, not an exact route segment. For example, /api also matches /api-admin. Use precise prefixes, usually with a trailing slash, and test adjacent routes.
No dedicated health endpoint
The metadata endpoint proves that the HTTP process can serve SP metadata, but not that the IdP login, session issuance, or backend proxy path works. Production monitoring needs an end-to-end test in addition to process supervision.
Fixed runtime limits
HTTP server and backend transport timeouts are currently fixed rather than configurable. In particular, the client-facing response write timeout is 30 seconds. This can affect slow uploads, downloads, streaming responses, and long-running backend requests. Review the complete runtime limits before deployment.
Identity data increases header size
The session JWT contains all mapped attributes and groups and is sent as a cookie on every protected browser request. The same data is expanded into backend headers. Users with many or long group values can exceed browser, TLS reverse proxy, or backend limits even before PassBeyond's server limit is reached.
No built-in rate limiting
PassBeyond does not provide request, login, or passthrough-token rate limiting. Apply suitable limits at the public reverse proxy while allowing legitimate SAML POSTs and application traffic. See Reverse proxy integrations.