Britive

B Cloud PAM (JIT / zero standing privilege) API

Britive service identities can authenticate with an ID token from any OIDC issuer you register (plus AWS STS and SPIFFE), so automation needs no static Britive token. Into your clouds it is keyless on AWS, GCP WIF, Azure WIF and OCI WIF, but Okta, Salesforce, Snowflake, Google Workspace and ServiceNow connectors still want a pasted token, password or key.

Docs: docs.britive.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

Federated service identities: the tenant trusts an OIDC identity provider you configure by issuer URL with allowed audiences and exact/regex claim-to-attribute mapping, and the workload sends its ID token as "Authorization: OIDC::<token>"; AWS STS (GetCallerIdentity) and SPIFFE JWT-SVID providers are also accepted. Static API tokens (1-90 days) remain available.

Issuers: any

docs.britive.com checked 2026-10-13
“Service identities are non-human identities used for non-interactive use cases like automation, scripting, etc.”
docs.britive.com checked 2026-10-13
“**Issuer Url**: This needs to be unique within a tenant.”
docs.britive.com checked 2026-10-13
“When calling Britive APIs with OIDC providers, make sure to use the OIDC token prefix in the authorization header **Authorization: OIDC::****{{****ID Token****}}.**”
docs.britive.com checked 2026-10-13
“**OIDC**: Enter **Name, Issuer Url,** and **Description**.”
docs.britive.com checked 2026-10-13
“**Allowed Audiences:** Edit a list of allowed audiences.”
docs.britive.com checked 2026-10-13
“**Regex**: The stored value is a regular expression, and the claim must match it.”
docs.britive.com checked 2026-10-13
“It includes support for workload federation, approvals, Britive administration, and many other features.”

Issuers are bring-your-own: any OIDC issuer URL (the docs use GitHub repo/branch claims as the example), plus one AWS STS provider and SPIFFE/SPIRE trust domains. Trust is constrained by issuer, allowed audience, a configurable iat validation window (default 30 seconds) and claim-to-attribute mapping (e.g. sub), and the effective token lifetime is the lesser of the ID token's exp and the service identity's configured validity. The older API prerequisites page still describes only static API tokens created by an admin in the UI. On-prem Access Broker agents register with a broker-pool authentication token (static, up to three per pool, two active), or an authentication_token_generator script that can fetch one dynamically; the docs do not describe federating the broker itself.

Outbound B

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

Britive is a SAML IdP trusted by an AWS IAM role (AssumeRoleWithSAML) and an OIDC issuer trusted by GCP Workload Identity Federation, an Azure app-registration federated credential, OCI and EKS; Okta (super-admin API token), Salesforce (password + security token), Snowflake (key pair), Google Workspace (service-account JSON key), ServiceNow (password) and the legacy GCP/Azure connectors (JSON key / client secret) still take static credentials.

docs.britive.com checked 2026-10-13
“Britive uses the SAML protocol as the authentication mechanism to connect to AWS.”
docs.britive.com checked 2026-10-13
“Only read-only access is needed here as the role is mainly used for scanning in Britive. Hence, write access is not required for the role.”
docs.britive.com checked 2026-10-13
“Britive tenant’s OAuth URL, for example: *https://<TENANT_BASE_URL>/api/auth/sso/oauth2.*This field can be copied from the onboarded Britive GCP WIF app→**Settings**→**Britive Issuer URL**.”
docs.britive.com checked 2026-10-13
“For a federated credential scenario, select **Other Issuer** in the dropdown menu.”
docs.britive.com checked 2026-10-13
“On the **Settings** tab, Britive automatically creates OIDC attributes to use when setting up the federation trust with the EKS cluster.”
docs.britive.com checked 2026-10-13
“Britive needs an API token with super administrator privileges that provides access to connect to Okta to read roles, users, and role assignments.”
docs.britive.com checked 2026-10-13
“Britive needs a service account that provides access to connect to Google Workspace to read roles, users, and IAM policies. After creating an account, the following items are required:”
docs.britive.com checked 2026-10-13
“Copy and paste the JSON of the service account key (credentials) that was generated when the service account was created”
docs.britive.com checked 2026-10-13
“Britive needs the following to onboard a Salesforce application:”
docs.britive.com checked 2026-10-13
“Provide the user's email address, password, and security token to the Britive administrator to complete the Salesforce configuration in Britive.”
docs.britive.com checked 2026-10-13
“Private and Public keys to connect to Snowflake REST APIs”
docs.britive.com checked 2026-10-13
“Copy and paste the JSON of the service account key (credentials) generated when the service account was created.”
docs.britive.com checked 2026-10-13
“If you select Never, the client secret never expires.”

Connectors checked: AWS (SAML IdP + IAM role, keyless), AWS Identity Center and AWS account access (same Britive SAML IdP pattern), GCP WIF (Britive is the OIDC issuer, keyless), GCP legacy (service-account JSON key), Azure WIF (federated credential, keyless), Azure legacy (client secret, docs mention a "Never" expiry option), OCI WIF (Britive issuer + confidential app; still asks for a confidential-app client ID), OCI 1.0/2.0 (user API signing key, plus client secret for provisioning), EKS (Britive OIDC issuer, keyless), Okta (API token with Super Administrator), Google Workspace (service-account JSON key with domain-wide delegation), Salesforce (user password + security token with Modify All Data), Snowflake (key pair for a user with MANAGE GRANTS / ORGADMIN), ServiceNow (user password). Every major cloud has a keyless option, which is better than most of the cohort, but every SaaS/IdP connector checked wants a static credential, so B. No GitHub or Microsoft 365 connector is documented; Entra ID appears only as an SSO/SCIM identity provider.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Judgment call. Every API token and static service-identity token must carry a 1-90 day validity, which looks like an enforced ceiling, but the counter resets on every use, so it is an inactivity timeout rather than an expiry: a token that is used regularly (including by whoever stole it) never expires. Short-lived temporary tokens (POST /api/tokens/temp, 24-hour platform cap, lower tenant maximum) exist but must themselves be minted by an authenticated caller. docs.britive.com checked 2026-10-13 “Any value between 1 and 90 days.” docs.britive.com checked 2026-10-13 “Enter the name and validity of the API token. Click Save. The validity counter is refreshed with every use of a token.”
✓ Rotation via API	POST /api/token creates, DELETE /api/token/{tokenId} revokes, and POST/PATCH /api/users/{targetUserId}/tokens replaces or re-dates a service identity's token. docs.britive.com checked 2026-10-13 “When this token is created, the old token associated with the identity provider is removed.” docs.britive.com checked 2026-10-13 “Use the Get tokens API call to retrieve the id of the token that should be revoked.”
✓ Scoped keys	Passes via service identities, which are purpose-built machine principals whose static token carries only the policies/profiles assigned to that identity. Plain admin API tokens do not scope: they inherit the creator's privileges, and POST /api/token is documented as creating "an API token with full administrator privileges". docs.britive.com checked 2026-10-13 “The token has the same privileges assigned to the identity.” docs.britive.com checked 2026-10-13 “Service identities are non-human identities used for non-interactive use cases like automation, scripting, etc.” docs.britive.com checked 2026-10-13 “API tokens inherit the same privileges as the user who created the tokens.”
✓ Last-used visible	The ApiTokenBean returned by GET /api/token includes a lastAccessed date-time field alongside createdOn, expiresOn, createdBy and type (DEFAULT, SCIM, ServiceIdentity). The field carries no description in the spec, and no UI documentation of it was found. docs.britive.com checked 2026-10-13 “Get all API tokens in the system”
✗ Leak revocation	Britive does not appear anywhere on GitHub's supported secret scanning patterns page. docs.github.com checked 2026-10-13

Notes

Graded the Britive Cloud PAM tenant API ({tenant}.britive-app.com/api), which the PyBritive CLI, Terraform provider and Access Broker all use. Docs are public at docs.britive.com, including a per-endpoint OpenAPI reference. The same tenant also runs Britive's secrets manager and an MCP gateway; they use the same token and service-identity model. The lastAccessed field and the 1-90 day validity range come from the published OpenAPI schema; behaviour was not tested against a live tenant.

Badge

[![wif.tax grade](https://wif.tax/badge/britive-cloud-pam.svg)](https://wif.tax/p/britive-cloud-pam/)