Skip to content

Managing Credentials

DIBOP takes credential security seriously. All credentials are encrypted at rest, stored in Azure Key Vault, and isolated per enterprise. This page explains how credentials are managed and how to rotate them when needed.

How Credentials Are Stored

When you configure a connection and enter credentials (API keys, OAuth2 secrets, passwords), DIBOP:

  1. Encrypts the credentials using AES-256 encryption before they leave the browser
  2. Stores them in Azure Key Vault -- a dedicated, enterprise-grade secrets manager
  3. References them by ID -- the DIBOP database stores only a reference to the vault secret, never the credential itself
  4. Decrypts at execution time -- credentials are retrieved and decrypted only at the moment an API call is made, then immediately discarded from memory

No Plaintext Storage

At no point are your credentials stored in plaintext in the DIBOP database. Even DIBOP platform administrators cannot view your credentials.

Enterprise Isolation

Credentials are strictly isolated by enterprise:

  • Each enterprise's credentials are stored under a unique key vault namespace
  • A credential belonging to Enterprise A is never accessible to Enterprise B
  • Platform administrators can see that a credential exists (for operational purposes), but cannot read its value
  • Deletion of an enterprise's account removes all associated credentials from the vault

Viewing Credential Status

Navigate to CONNECT > My Connections and click on a connection to view its credential status.

You will see:

Field Description
Auth Type The authentication method (API Key, OAuth2, Basic Auth)
Last Updated When the credentials were last modified
Status Whether the credentials are currently valid (based on the last health check)
Expires For OAuth2 tokens, when the current access token expires

Masked Values

Credential values are never displayed in the UI. You will see masked representations (e.g., ****def456) for identification purposes only.

Rotating Credentials

Credential rotation is the process of replacing old credentials with new ones. You should rotate credentials:

  • When mandated by your security policy (e.g., every 90 days)
  • When a credential may have been compromised
  • When an employee with access to the credentials leaves the organisation
  • When the external system issues new credentials

How to Rotate

  1. Navigate to CONNECT > My Connections
  2. Click on the connection whose credentials you want to rotate
  3. Click Update Credentials
  4. Enter the new credential values
  5. Click Test Connection to verify the new credentials work
  6. Click Save

Zero-Downtime Rotation

DIBOP swaps credentials atomically. There is no window during which the old credentials have been removed but the new ones are not yet active. Running orchestrations will use the new credentials starting with their next API call.

OAuth2 Token Management

For OAuth2 connections, DIBOP manages the token lifecycle automatically:

Action When It Happens
Token Request When the connection is first activated, or after a token expires
Token Caching Active tokens are cached in memory to avoid redundant requests
Token Refresh If a refresh token is available, DIBOP uses it to obtain a new access token before the current one expires
Token Revocation When a connection is deleted, DIBOP revokes any active tokens (if the provider supports revocation)

You do not need to manage tokens manually. If you rotate the client ID/secret, DIBOP will request a new token using the updated credentials.

Credential Validation

DIBOP validates credentials in several ways:

At Configuration Time

When you enter or update credentials and click Test Connection, DIBOP attempts to authenticate with the external system using the provided credentials. The test result tells you immediately whether the credentials are valid.

At Execution Time

If an API call fails with an authentication error (HTTP 401 or 403), DIBOP:

  1. Logs the failure in the API Call Log
  2. Marks the connection's health status as degraded
  3. Triggers any configured alert rules for authentication failures

Periodic Health Checks

DIBOP periodically pings each active connection to verify it is reachable and authenticated. If a health check fails due to expired or invalid credentials, the connection status changes to Offline and an alert is generated.

Best Practices

Practice Why
Rotate credentials regularly Reduces the risk window if credentials are compromised
Use OAuth2 where available Tokens expire and refresh automatically, reducing manual rotation
Use dedicated service accounts Avoid using personal credentials that might be revoked when someone leaves
Monitor auth failures Set up alert rules for 401/403 errors to catch credential issues early
Use sandbox credentials for testing Never use production credentials in test orchestrations
Error Meaning Action
AUTH_FAILED The external system rejected the credentials Verify credentials are correct and not expired
TOKEN_EXPIRED The OAuth2 access token has expired and refresh failed Update the client secret or re-authorise
CREDENTIAL_NOT_FOUND The credential reference in Key Vault could not be resolved Contact your platform administrator
DECRYPTION_ERROR The credential could not be decrypted This is a platform-level issue; contact support

Next Steps