AWS Cognito: NotAuthorizedException: Unable to verify secret hash for client x
The app client has a client secret, so every request needs a SECRET_HASH — and it’s missing or computed wrongly.
Seen on:
REST API
Meaning
Browser/mobile apps shouldn’t use clients with secrets. For server-side use, SECRET_HASH = Base64(HMAC_SHA256(client_secret, username + client_id)). Using email vs username (sub) changes the hash.
Common causes
- Public (browser/mobile) app using a client that has a secret
- SECRET_HASH not sent
- Hash computed with the wrong username/alias
- Wrong client secret
⚡ Quick fix
- Create an app client without a secret for public apps
- Compute SECRET_HASH server-side with the exact username
- Verify client ID/secret pair
Detailed fix by platform
Python
- python
import hmac, hashlib, base64 secret_hash = base64.b64encode(hmac.new(client_secret.encode(), (username + client_id).encode(), hashlib.sha256).digest()).decode()
How to diagnose
- Client — Has a secret?
- Username — Same value used in hash and request
🔧 Still not fixed?
Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:
Similar errors
- auth/invalid-credential Firebase Auth: auth/invalid-credential (auth/wrong-password, auth/user-not-found, auth/invalid-login-credentials)
- auth/network-request-failed Firebase Auth: auth/network-request-failed — A network AuthError (such as timeout, interrupted connection or unreachable host) has occurred
- Clock skew too great Kerberos: Clock skew too great (KRB_AP_ERR_SKEW)
Most viewed in Authentication
Other ways to find it
🧠 Still stuck? Analyze your error
Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.
Was this page helpful?
Report a correction or suggest an improvement
Last updated 7 Oct 2026