wif.tax

BeyondTrust

D Password Safe (Cloud and Pathfinder) public API

Workloads call the Password Safe public API with an OAuth client ID and secret (short-lived tokens, secret expires after 365 days by default) or with a static API key plus a RunAs user name. There is no federation for Password Safe itself; BeyondTrust's newer Workload Credentials product accepts OIDC tokens. API keys never expire and are not GitHub partner-revoked. Cloud discovery and Entra ID or Google account management want a static AWS key, Azure client secret or GCP key file.

Docs: docs.beyondtrust.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

OAuth 2.0 client_credentials at /auth/connect/token: an application user's Client ID and Client Secret buy a bearer token whose lifetime is set on its API Access Policy registration. The older path is a static API key sent as "PS-Auth key=...; runas=user", gated by mandatory source-IP or PSRUN rules and optionally a client certificate, user password or personal access token.

Graded on the Password Safe public API (/BeyondTrust/api/public/v3), which is the only way to automate Password Safe Cloud and Password Safe on Pathfinder (retrieving managed credentials, Secrets Safe, onboarding, API registrations). Its two auth paths are OAuth client_credentials for application users and API key + RunAs user; neither accepts an external OIDC token, so the best path is a client secret exchanged for a short-lived token: C. IP/PSRUN rules and an optional client certificate (any cert chained to a CA the server trusts) add factors but not federation. Pathfinder has a real bring-your-own-issuer exchange (Security > Workload Identities: GitHub Actions, Entra ID or any custom issuer, with sub and other claim conditions), but it is documented for Workload Credentials, a separate product that BeyondTrust itself contrasts with Password Safe. The workload-identity form lets you pick "products" per site, but no Password Safe doc says the public API accepts that token, and the SignAppin page lists only Application, Local and directory users. Not publicly verifiable beyond that; if Password Safe on Pathfinder is selectable as a workload-identity product scope and its API takes the exchanged token, inbound would move to A (Pathfinder only). The Pathfinder platform Authentication API itself takes an org-admin PAT.

Outbound D

How this product reaches into your cloud, repos, or other SaaS.

Cloud discovery connectors take a static AWS access key ID and secret, an Azure app client ID and client secret, or a Google service-account key file; Entra ID and Google Workspace account management take an Entra client secret or a GCP service-account JSON key with domain-wide delegation. Least-privilege permissions are documented for each.

Checked: cloud discovery connectors (AWS, Azure, Google Cloud, plus Hyper-V and Rackspace with username/password or API key), the Entra ID functional account, the Google Cloud / Workspace platform, Entra ID directory users (client secret via API), and Secrets Safe (no outbound sync to cloud secret stores documented). Every cloud reach-in needs a long-lived secret: AWS IAM user keys (the connector page mentions optional ARN/External Name fields for third-party access, but Access Key ID and secret remain required), an Entra client secret, and a GCP service-account key (skippable only for self-hosted BeyondInsight running on GCP, which does not apply to the SaaS). The Entra secret is a customer-managed app secret that would be C on its own, but AWS and GCP drag the surface to static keys. Each comes with a minimal permission list (EC2/ELB describe actions, Reader or a custom Azure role, Compute Network Viewer), so D rather than F; no rotation guidance for these connector credentials was found. Managing privileged accounts necessarily means holding functional-account credentials for target systems; graded here only on how Password Safe authenticates to cloud and SaaS control planes. The sibling Workload Credentials product does it keylessly (AWS role with an external ID), which shows the gap.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Split verdict, graded on the weaker credential. API keys (API Key Policy registrations) have no expiry field in the registration model or console and live until someone rotates them: fail. OAuth client secrets do expire, 365 days by default, with a site-wide Client Secret Expiry setting under Authentication Options, which would pass on its own (whether that setting accepts an unlimited value is not documented). Same handling as twilio-api, where a never-expiring key path sits beside a better one.
  • docs.beyondtrust.com checked 2026-10-22
    “Once the key has been changed, any script using the old key receives a "401 Unauthorized" error until the new key is used in its place.”
  • docs.beyondtrust.com checked 2026-10-22
    “Can be either "apikeypolicy" or "apiaccesspolicy"”
  • docs.beyondtrust.com checked 2026-10-22
    “The default duration of a client secret is 365 days.”
✓ Rotation via API
POST /apiregistrations/{id}/rotate and POST /users/{id}/RecycleClientSecret rotate either credential; registrations and users can also be created and deleted through the API.
✓ Scoped keys
Application users are purpose-built machine principals that cannot sign in to the console and get only the feature permissions and Smart Rule roles of the groups they join. An API key acts as its RunAs user, which can be a human's account with that human's full access, but the key is also limited to users in groups granted that registration and to its source IPs.
  • docs.beyondtrust.com checked 2026-10-22
    “Application Users are service accounts that represent any non-human identity that needs access to secrets and credentials.”
  • docs.beyondtrust.com checked 2026-10-22
    “Assign the user to a group that has the required permissions to access BeyondInsight and Password Safe features.”
  • docs.beyondtrust.com checked 2026-10-22
    “A user group to which the user belongs must be granted access to the API key given in authorization header”
✗ Last-used visible
No last-used field or column is documented for API registrations or for client secrets; the Users grid shows OAuth Secret Expiry, not last use. Users expose last login information, and User Audit records sign-ins, so an application user's last activity can be approximated, but an API key is used as whichever RunAs user is named, so a dead key cannot be spotted from that. A per-registration last-used timestamp would flip this.
  • docs.beyondtrust.com checked 2026-10-22
    “Get a specific user by their unique identifier with last login information.”
  • docs.beyondtrust.com checked 2026-10-22
    “Read access and rotation of the key is audited.”
✗ Leak revocation
BeyondTrust does not appear in GitHub's supported secret-scanning patterns table, as partner or user pattern, so a leaked API key or client secret is not reported for revocation.

Notes

One card for Password Safe Cloud and Password Safe on the Pathfinder platform, which share the BeyondInsight/Password Safe public API v3 and its API registrations (Pathfinder blocks the user-password and MFA factors on API keys). Self-hosted Password Safe/BeyondInsight uses the same API and auth. Siblings not graded here: Workload Credentials on Pathfinder (OIDC federation from GitHub Actions, Kubernetes, Entra ID or a custom issuer; keyless AWS connector), Privileged Remote Access, Remote Support and Entitle. Two of five hygiene checks pass. Inbound moves to A if the Pathfinder workload-identity exchange is documented as working for the Password Safe API; outbound moves to B or A with role-based AWS and federated Azure/GCP connectors. An expiry on API keys, a last-used timestamp and GitHub partner revocation would fix hygiene.

Badge

wif.tax grade D

[![wif.tax grade](https://wif.tax/badge/beyondtrust-password-safe.svg)](https://wif.tax/p/beyondtrust-password-safe/)