Enable Hashed Client Secret

The client ID and client secret comprise the OAuth client credentials used for OAuth authorization of non-public apps. The client secret is a shared secret known to the application and the authorization server. Hashing it is recommended for security reasons. One-way hashing of the client ID and client secret provides additional security against attackers is by hiding the plaintext OAuth credential values from view in both the interface and the database.
The client secret initially appears as plaintext after generation. This allows you to copy and provide it to the app developer. If hashing of the client secret is enforced or selected, this initial view is your only opportunity to copy the OAuth credential. For all subsequent visits to the page, the OAuth credential appears as a string of asterisks.
Enable Hashed Client Secret
Enabling hashed client secrets affects newly created applications. It does not impact existing apps.
To configure the format of shared secrets:
  1. Log in to the API Portal as an administrator.
  2. From the menu bar, select gear icon,
    Settings
    .
  3. In the
    Application Shared Secret Security
    section, select one or both of the following options:
    • Allow plaintext secrets
    • Allow hashed secrets
  4. If you select
    Allow hashed secrets
    , choose one of the following supported hashing algorithms, and then click
    Save
    :
    • SHA-512
    • SHA-384
    • SHA-256
    • SHA-1
    • MD5
    Portal does not support HMAC versions.
Consequences of Hashed Client Secrets
Allowing for hashed client secrets results in the following consequences:
  • Support for hashed OAuth credentials is introduced with OTK 4.4. You cannot sync applications created with client secret hashing enabled on proxies running versions of OTK 4.3 or earlier. You can sync applications with plaintext client secrets on all versions of OTK.
  • Portal records sync failures due to hashed credentials and incompatible OTK version and displays these under the
    Deployments
    tab of the application. Error messages appear in the sync log.
Generate a New Client Secret
You can always generate a new secret for the application. This can be useful if your shared secret is compromised. When you generate a new shared secret, the API proxy no longer accepts queries that use the old secret. The app developer must update the shared secret in their application before their application can access the APIs.
To generate a new client secret:
  1. Go to
    Manage, Applications
    .
  2. Click on the application for which to generate a new client secret. Select
    Action > Edit Keys
    .
  3. In the
    Authentication & Keys
    section, click on the API key for which to generate a new client secret.
  4. Under
    Shared Secret (Client Secret)
    , click
    Generate New Secret
    .
  5. A new client secret is generated in plaintext. A notification appears, reminding you that generating a new key breaks access for anyone using the previously-issued key.
  6. Copy the value and provide both the client ID and new client secret to the app developer.
    If client secret hashing is enabled, this is your only opportunity to copy the value. Do NOT click Save Key before copying the value.
  7. If your Portal is configured to allow generation of client secrets in plaintext or hashed format, an option appears to select your preferred type. Select your
    Secret Type
    .
  8. Click
    Save Key
    .