On a Monday morning catchup, one of our senior engineers — embedded full-time with a client whose admin surface runs on Microsoft Azure — described a problem that had quietly eaten up most of the previous week. He was building Cypress end-to-end tests against a set of Azure AD-protected admin portals, and Microsoft was refusing to let the test suite log in.
The specific error, for any engineer who's Googled their way here: AADSTS9002327 — a message that, loosely translated, means "this token was issued for a Single-Page Application client and cannot be redeemed in this context."
His read was correct, and honest: this is deliberate. Microsoft's portals block automated browser sessions by design, to prevent bot abuse. "Makes sense," he said. "The portals have this kind of security block just to prevent bot usage." He'd spent days digging for workarounds. None of them worked.
At this point, most organizations running staff-augmentation engagements would leave the engineer to his own devices. He'd keep researching, burn more hours, eventually escalate to the client, and either find a hack or quietly lower the coverage goal. That's the default pattern when engineers are contracted in isolation.
At Admios, we do regular catchups with every engineer on every account. Not a status report — a real conversation. The value of those meetings is almost never the engineer's own update; it's what the conversation surfaces that nobody else would have seen. In this case, what surfaced was a testing problem that sounded a lot like something a different engineer, on a different account, had recently worked through.
So we opened a group Slack conversation. Our senior QA automation engineer on another client account — someone this engineer had never directly worked with — got pulled into the conversation. The intro took about ninety seconds to write.
The QA engineer's first message was the kind of thing you rarely see from an engineer trying to impress a new audience:
"I actually haven't faced this specific issue myself yet, but doing a bit of research on it, it seems to be a very common issue when mixing Cypress with Azure AD."
That opening matters. Nobody grandstanded. Nobody pretended to know more than they did. And then came real substance: Cypress, he explained, runs its tests inside an iframe and acts as a proxy for network requests. During token redemption, Cypress can alter or strip the Origin header — and Microsoft's cross-origin security flow for Single-Page Applications considers that disqualifying.
The Cypress community's recommended workaround, he noted, is to stop using UI login altogether for E2E tests. Instead, do a programmatic login: use cy.request() to hit Microsoft's token endpoint directly, retrieve an access token, and inject it into the browser's session storage. The test logs the user in without ever touching the blue Microsoft sign-in screen.
He added one more warning — the kind that only comes from experience: for the programmatic flow to work at all, the test user in Azure AD has to be set up without MFA or Conditional Access enforced. Otherwise the token request itself gets blocked.
Our senior engineer took the direction and ran with it. Within a few hours he had working code — a Cypress task that hit Microsoft's OAuth endpoint, collected an access token, and returned it cleanly. The shape of it looked roughly like this:
Then he hit the actual wall.
The Azure Portal UI — the thing his tests actually needed to drive — doesn't accept bearer tokens. The portal authenticates with session cookies, not API tokens. No amount of programmatic-login cleverness was going to sign a Cypress-controlled browser into the portal itself. Microsoft has designed that flow specifically so nothing but an interactive human session can get in.
This is the part of the story most "we solved it!" case studies skip, and it's the part worth dwelling on: sometimes the right engineering answer is to not write the test.
At his client's team sync that same afternoon, the engineer presented the findings. The client lead's response was the right one: document the boundary for other engineers, note what was and wasn't automatable, and skip the Azure Portal tests rather than continuing to burn time on a category of problem that has no clean solution. Test coverage goals were adjusted to reflect what's actually automatable — not what sounded nice in the original test plan.
That's senior engineering judgment. It's also, quietly, exactly the kind of decision that saves clients money.
Two things made the afternoon work, and both are structural — not heroic.
First: cross-account engineer collaboration is a real thing, not a marketing line. Our engineers work on different client accounts, in different countries, on different stacks. They help each other anyway — because they're on the same team, paid by the same company, and because helping another engineer is part of the job, not a distraction from it. A freelancer marketplace can't replicate this. A contractor staffed through a broker can't either. It requires an actual team and an actual culture.
Second: team leaders have to hear the briefings. Those catchups are where the pattern got spotted. If nobody outside the engagement had ever heard this engineer describe his Cypress problem out loud, nothing connects. The manager's role in a nearshore consultancy isn't to manage the engineer's day-to-day work — the client does that. The manager's role is to know enough about what every engineer is doing to recognize, across a portfolio of accounts, which problems on Monday are variants of problems somebody else solved last month. That only works if you're actually regularly sitting down with every engineer and paying attention.
Structurally, it's a small investment. Twenty or thirty minutes per engineer. The payoff, in this case, was roughly a week of engineering time recovered, a reusable artifact left behind (the documentation the client's team now has), and an engineer who isn't heading into the next sprint carrying an unresolved blocker in his head.
Both engineers used Claude during this investigation. Neither of them relied on it. The AI surfaced hypotheses — about Origin headers, about ROPC flows, about bearer-token limitations — that the engineers then validated or disproved against real code and real client infrastructure. The final conclusion (session-based authentication, not bearer tokens, at the portal UI itself) wasn't in any AI's first suggestion. It took human eyes on a working code sample to find the real boundary.
That's the model we're investing in. AI accelerates the investigation. Engineers make the judgment call.
Shared with permission of the engineers involved. All client names, specific project details, and tenant-specific code have been omitted.
