I need to automate access to an internally hosted website from PowerShell. The site uses Azure-based SAML single sign-on, and one of the final requests appears to require a SAMLResponse value. I have inspected the browser's network traffic but cannot find the assertion clearly enough to reproduce the login with Invoke-WebRequest. The process must run unattended on a server where installing or launching a full browser may not be possible, and it needs to remain reliable indefinitely. What is the recommended way to authenticate and maintain a session in this situation?
5 Answers
After a successful SAML handoff, the application generally establishes its own session cookie. Reusing that cookie in a PowerShell WebRequestSession can work for short-lived scripts, but it is not a durable authentication design: cookies expire, sessions can be revoked, and conditional-access policies may require fresh authentication. Avoid extracting or replaying a user's browser cookies for an indefinite company process unless the application owner explicitly supports it.
It is technically possible to recreate the full flow by parsing the initial HTML and JavaScript, posting each SAML or login form in sequence, and preserving cookies between requests. However, hidden fields, JavaScript-generated values, MFA, anti-forgery tokens, and changes to the identity provider make this effectively reverse engineering. Treat it as a temporary proof of concept, not a production integration. The sustainable fix is an API or a formally supported noninteractive authentication method.
If there is no usable API and the site genuinely requires interactive SSO, use browser automation such as Selenium, Playwright, or WebView2. These can follow JavaScript redirects, hidden form fields, MFA steps, and cookie handling that a plain HTTP client will miss. A headless browser may work, but only if the identity provider permits unattended authentication and does not require an interactive MFA or CAPTCHA challenge.
For a long-running process, reproducing the web login with Invoke-WebRequest is usually the wrong solution. Ask the application owners for a supported API or service-to-service authentication flow. If the application exposes an API, an app registration with the appropriate OAuth permissions, certificate authentication, client credentials, or a managed identity is much more maintainable than impersonating a user session. Store any secrets in the company's secret-management system rather than in the script.
The SAMLResponse is normally generated by the identity provider and submitted by the browser to the service provider's assertion consumer service (ACS) endpoint. It is usually a base64-encoded value in the POST body of that handoff, not something returned by the final application page. Identify the ACS or consumer URL and inspect the request that posts to it. A SAML-tracing tool can make that exchange easier to understand, but be careful because assertions can contain sensitive authentication data.
I found the requests around the identity-provider redirect, but I still need this to run unattended and reliably rather than depending on a captured browser value.
A browser engine is still required for those tools, even when it runs headlessly. If the server cannot run one at all, the remaining option is to manually reproduce every request and state transition, which is fragile and likely to break when the identity provider changes.