Configure AppViewX to authenticate to CryptoHub

AppViewX authenticates to the CryptoHub REST API with the endpoint credentials from the deployed AppViewX service, and carries the returned token on every subsequent call.

Store the CryptoHub credentials

Store the endpoint username and password in the AppViewX vault so the workflow reads them at run time rather than carrying them inline. The CryptoHub login endpoint expects the password Base64 encoded. Store the encoded value.

Shell

printf '%s' '<password>' | base64

Base64 is an encoding, not encryption. The encoded password is as sensitive as the original. Keep it in the AppViewX vault and out of workflow definitions, exported configuration, and logs.

Configure the authentication call

AppViewX authenticates against /home/v1/login with authType set to userpass.

Request

{
  "authCredentials": {
    "username": "<identity username>",
    "password": "<Base64-encoded password>"
  },
  "authType": "userpass"
}

The response carries the session token in token and its expiry in tokenExpiration.

The response is similar to the following:

Response

{
  "token": "<JWT>",
  "tokenExpiration": "2026-07-29 12:34:56",
  "fullyLoggedIn": true
}

For the full request and response contract, including the other response fields, see Login.

If the identity belongs to a role that requires multiple identities, the session reports fullyLoggedIn: false until enough identities have authenticated. The endpoint identity used for unattended automation should be scoped so that a single login fully authenticates the session.

Carry the token on subsequent calls

Send the token in the Authorization header on each following request:

Shell

Authorization: Bearer <JWT>

Configure AppViewX to read tokenExpiration and re-authenticate when the token expires, rather than assuming a fixed lifetime. For the token handling patterns CryptoHub supports, including the stateless and session-based flows, see Using bearer tokens.

The token lifetime is set by CryptoHub, not by the client, and is deployment dependent. In testing against CryptoHub 7.0.3.x the token remained valid for roughly 24 hours, well beyond the fixed 10-minute interval some workflow templates assume. Always honor the tokenExpiration timestamp returned at login rather than a hardcoded lifetime.

Handle authentication failure

If authentication fails, the workflow must stop rather than continue to the key generation step. A failed login leaves no CryptoHub objects behind, so no cleanup is required. Verify the following when a login fails:

The password is Base64 encoded.
The username matches the endpoint identity, not an administrator identity.
The endpoint’s partition is enabled.
The CryptoHub address resolves and is reachable over HTTPS from the AppViewX host.

Next steps

Generate the key pair and certificate signing request. See Generate a key pair and CSR in CryptoHub.

​Store the CryptoHub credentials

​Configure the authentication call

​Carry the token on subsequent calls

​Handle authentication failure

​Next steps

Store the CryptoHub credentials

Configure the authentication call

Carry the token on subsequent calls

Handle authentication failure

Next steps