Authenticating via Microsoft Azure AD in Cypress (and Puppeteer)

Colin Wren
3 min readFeb 25, 2023

Recently I found myself having to automate a Single Sign On (SSO) implementation that used Microsoft Azure AD as the indentity provider and encountered some issues which I thought were worth sharing.

It’s worth noting that what I’m about to describe is an anti-pattern in Cypress, they recommend not automating 3rd party systems, instead using stubs or mock services but I found myself having to perform an end-to-end system test to cover the SSO implementation.

How does SSO with Azure work?

SAML 2.0 authentication sequence diagram from https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol

When a user signs in with SSO they use an existing service they use (called an identity provider) to verify that they have an account and what permissions they have (based on roles or groups assigned to them), once the use has logged into the identity provider it then redirects them back to the application they’re trying to log in with tokens that contain information about the user that can then be used to create a new session (and account if needed).

There are a number of different standards that provide this functionality such as SAML 2.0, OAuth 2.0 and OpenID Connect but from the perspective of the end user (and automation) the flow remains the same with them pressing a button to login, being redirected to Microsoft and then back into the app as an authenticated user.

What issues did Cypress have with SSO via Azure AD?

When automating the SSO flow with Azure AD one of two issues would happen:

  • On redirecting into Azure the Microsoft login page wouldn’t load and then I’d see a 414 URI too long error page
  • The Microsoft login page would load but on submitting the password form the page would get stuck in a loading state

The first issue looks to have been caused by Cypress running the website under test in an iframe and that was tripping up Microsoft’s login form as it was trying to cater for the iframe. This issue has been captured here: https://github.com/cypress-io/cypress/issues/7619

I wasn’t able to find a reason for the second issue but I can only assume it was somewhat iframe related, maybe a check on the Microsoft backend tripped it up.

--

--

Colin Wren

Currently building reciprocal.dev. Interested in building shared understanding, Automated Testing, Dev practises, Metal, Chiptune. All views my own.