5.4REST API security

The further network automation goes, the more API credentials become as powerful as a device's privileged password—or more so: a token that can call Catalyst Center's Intent API can change hundreds of devices in a single request. ENCOR treats this area not as "how to use an API" but as diagnosis and remediation: what is dangerous in this script, why does production return 401 or 429, and what does disabling certificate validation with verify=False actually break? The theme is balancing automation's convenience against control of credentials, privileges, and request volume.

5.4.1Authentication and authorization (tokens and OAuth)

• Most controller APIs use a two-stage flow: first send the username/password with Basic authentication to a token endpoint such as /dna/system/api/v1/auth/token, then carry the returned token in the X-Auth-Token (or Authorization: Bearer ...) header on subsequent requests. Tokens have an expiry, and expiration surfaces as 401 Unauthorized—the benefit being that the password need not be sent on every call.
• OAuth 2.0 is the standard for delegating limited authority to third-party applications without handing over a password. Access tokens carry a scope (the permitted operations) and a short lifetime, and are renewed with a refresh token. The essential benefit is that a leak is bounded by scope and expiry—the decisive difference from embedding a shared account password in a script.
• HTTP status codes are the starting point for diagnosis: 401 means authentication failure or an expired token (re-authenticate), 403 means authentication succeeded but privileges are insufficient (a role/scope problem that re-authentication will not fix), 404 means a wrong resource or path, 429 means rate limit exceeded, and 5xx is server-side. Confusing 401 with 403 leads to endlessly retrying token retrieval for what is really a permissions problem.