A NOC developer must poll SD-WAN Manager for alarms every five minutes from a Python service without storing admin passwords, and POST requests fail after login succeeds. The script uses HTTPS to port 8443. Which REST API authentication approach establishes the session token and CSRF protection?

The SD-WAN Manager REST API on port 8443 requires an initial POST to the login resource with username and password to create a server session identified by the JSESSIONID cookie, followed by a GET to obtain the XSRF token that must be returned as the X-XSRF-TOKEN header alongside the cookie on all subsequent POST, PUT and DELETE calls, which explains why login can succeed yet later POSTs are rejected with forbidden errors when the token is missing. Sending only the session cookie without fetching and attaching the XSRF token satisfies authentication but fails CSRF protection, so read-only GET polling may work while alarm acknowledgement or other state-changing POSTs will be denied. Reusing a previously captured cookie and token pair indefinitely appears efficient and avoids storing admin passwords, yet sessions expire and tokens are rotated, so a five-minute unattended Python service will fail after timeout and cannot re-establish context without implementing the login flow. Using HTTP to port 8080 instead of HTTPS to port 8443 describes a plausible enterprise login pattern but violates the stated transport and management-interface fact for SD-WAN Manager, will not reach the authenticated API endpoint, and exposes credentials in clear text. For exam purposes, remember that JSESSIONID alone proves identity while the XSRF token proves the request originated from the authenticated session, and both are mandatory for writes. As a practical check, verify successful login by inspecting Set-Cookie for JSESSIONID, retrieve the token endpoint, then confirm later requests include Cookie and X-XSRF-TOKEN headers and handle 401 or 403 by triggering re-login before the next polling cycle.