5.4REST API セキュリティ

ネットワーク自動化が進むほど、API 資格情報は装置の特権パスワードと同等かそれ以上に強力になります。Catalyst Center の Intent API を叩けるトークンは、数百台の設定変更を1回のリクエストで実行できるからです。ENCOR ではこの領域を「API の使い方」ではなく、「このスクリプトのどこが危険か」「なぜ本番で 401 や 429 が出るのか」「証明書検証を無効化する verify=False は何を壊すか」という診断・是正として問われます。自動化の利便性と、資格情報・権限・流量の統制を両立させる判断が主題です。

5.4.1認証と認可（トークンと OAuth）

• 多くのコントローラ API は二段構えを取る：まず /dna/system/api/v1/auth/token のようなトークン発行エンドポイントへ Basic 認証でユーザ名/パスワードを送り、返ってきたトークンを以降のリクエストの X-Auth-Token（または Authorization: Bearer ...）ヘッダに載せる。トークンには有効期限があり、期限切れは 401 Unauthorized として現れる——毎回パスワードを送らずに済むのが利点である。
• OAuth 2.0 は、第三者アプリにパスワードを渡さずに限定的な権限を委譲するための標準。アクセストークンにはスコープ（許可される操作範囲）と短い有効期限を設定し、リフレッシュトークンで更新する。漏洩時の被害範囲がスコープと期限に限定されるのが本質的な利点で、「共有アカウントのパスワードをスクリプトに埋める」運用との決定的な差である。
• HTTP ステータスは診断の起点になる：401＝認証失敗/トークン期限切れ（再認証が必要）、403＝認証は成功したが権限不足（ロール/スコープの問題であり再認証しても解決しない）、404＝リソース/パス誤り、429＝レート制限超過、5xx＝サーバ側。401 と 403 の切り分けを誤ると、権限問題をトークン再取得で延々リトライすることになる。