Enable Hashed Client Secret
The client ID and client secret comprise the OAuth client credentials used for OAuth authorization of non-public apps. Hashing the client secret is recommended for security reasons.
The client secret is a shared secret known to the application and the authorization server. It must be copied in plaintext and provided to the app developer. One-way hashing of the client secret and client ID provides additional security against attackers 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 the client secret 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.
Enabling Hashed Client Secret
Enabling hashed client secrets affects newly created applications. It does not impact existing apps.
To configure the format of shared secrets:
- Log in to the API Portal as an administrator.
- In theApplication Shared Secret Securitysection, check one or both of the following options:
- Allow plaintext secrets
- Allow hashed secrets
- If you checked Allow hashed secrets, choose one of the following supported hashing algorithms:
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. Applications created with client secret hashing enabled cannot be synched on proxies running versions of OTK 4.3 or earlier. Applications with plaintext client secrets can be synched on all versions of OTK.
- Sync failures due to hashed credentials and incompatible OTK version are recorded and appear under the Deployments tab of the application. Error messages appear in the sync log
Regenerating a 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 developer must update the shared secret in the application before the application can access the APIs.
- ClickGenerate New Secret. A dialog box appears. The first selection box is mandatory, reminding you that generating a new key will break access for anyone using the old key.
- If your Portal is configured to allow generation of client secrets in plaintext or hashed format, a second selection box asks you whether you want to use a non-secure plaintext key. You must check the box to generate a plaintext secret, otherwise leave the box unchecked and a hashed secret is generated.
- When the new key is generated, the client secret is initially displayed in plaintext. Copy the value and provide both the client ID and client secret to the developer. If client secret hashing is enabled, this is the only time you have to copy the value.