Overview

Amazon’s Login with Amazon (LWA) client ID and client secret are the authentication keys that enable sellers to call the Selling Partner API (SP‑API). If those keys become publicly visible, Amazon instantly revokes the associated SP‑API permissions to protect buyer data. Keeping LWA credentials locked down is therefore a non‑negotiable requirement for every Amazon seller‑developer.

Key Points

• Immediate revocation — A confirmed exposure of either the client ID or the secret triggers an automatic suspension of SP‑API access for the affected developer account, cutting off all data calls within minutes.
• Broad data exposure — With compromised credentials, an attacker can request order details, inventory snapshots, and financial statements, putting both the seller’s operations and buyer privacy at risk.
• Indefinite lifespan — LWA client secrets remain active until the seller manually rotates or deletes them; they do not expire on a set schedule, so neglecting rotation creates a long‑term attack surface.
• Separate environments — Production and sandbox client IDs and secrets must be stored in distinct vaults and never mixed in a single repository, preventing a sandbox leak from compromising live sales data.
• Audit trail requirement — Amazon expects sellers to retain logs that capture when credentials are created, accessed, rotated, or revoked, enabling forensic analysis after any incident.
• Least‑privilege access — Only the services and team members that need to request an OAuth token should have read permission on the secret store; all other identities must be denied by default.

How LWA Client Credential Security Works

1. Credential generation — When a seller registers a new application in the Amazon Developer Console, Amazon issues a unique client ID (e.g., amzn1.application-oa2-client.1234567890abcdef) and a 40‑character secret string. The secret is displayed only once, forcing the developer to copy it to a secure location immediately.
2. Secure storage — The secret must be placed in an encrypted secret manager such as AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. For instance, a Java microservice can retrieve the secret at runtime via an IAM role that grants on the specific secret ARN.