A bank automation service polls SD-WAN Manager nightly for alarms and pushes template tweaks, requiring a persistent API session with CSRF protection across calls. Which authentication flow establishes the Manager API session with cookie and token?
Select an answer to reveal the explanation.
Short Explanation
You are opening a guarded session in the right order so later calls get trusted. Your handshake runs like a coat check where you keep the ticket for each return.
Full Explanation
The correct flow first posts credentials to j_security_check, which establishes the Manager session and returns the JSESSIONID cookie. The client must retain that cookie, request the CSRF token in the authenticated session, and send the token in the required header on subsequent API calls. Together, the cookie and token bind the requests to the authenticated session while providing CSRF protection. OAuth 2.0 client credentials is a standard automation pattern, but its bearer access token does not establish the cookie-backed SD-WAN Manager API session described here. HTTP Basic over TLS is also widely used for APIs, but sending credentials on each request—even over a reused connection—does not create the required persistent cookie session. The query-parameter approach does establish a session and obtains a token, but placing the CSRF token in the URL is not the required header-based use and can expose it through logs or URL handling. Exam caveat: distinguish the Manager’s documented session-authentication sequence from general API authentication patterns; a valid method in another API is not necessarily supported here. Practical check: inspect a test login’s Set-Cookie response, preserve JSESSIONID, retrieve the token using that session, and verify subsequent calls include both the cookie and the token header.