Azure Database for PostgreSQL: Authentication failure with SQLSTATE 28000 despite MFA claim in token

Hi Casper Andreas Solbakken & thx for join me at Q&A platform,

The distinction here is between MFA being recorded in the Entra access token and Azure Database for PostgreSQL accepting that token for a role with isMfa=true.

Microsoft's documentation says that isMfa checks the mfa claim in the access token, but it doesn't clearly specify whether the server evaluates amr, expects another claim representation, or has additional validation requirements. So I wouldn't assume that amr: ["pwd", "mfa"] guarantees the PostgreSQL-side check will pass.

There's also no documented token request parameter that simply adds a top-level mfa claim. That isn't something I'd try to manufacture by modifying the JWT, as the token signature would no longer be valid.

I'd first isolate the driver from the server-side authentication check. Acquire a fresh token using:

az account get-access-token --resource-type oss-rdbms

Then test that token directly with psql, using the same PostgreSQL role and database. Check that the token's aud, tid, oid, amr, and expiration are correct, and confirm that the exact token being inspected is the one passed as the PostgreSQL password. The most useful diagnostic is whether the same token succeeds with isMfa=false but fails with isMfa=true. If that's reproducible through psql as well as node-postgres, it strongly narrows the issue to the MFA enforcement path rather than the Node.js driver or connection handling.

I'd also distinguish between a delegated user token and an application or managed identity token. For an unattended Azure-hosted container, managed identity with a properly restricted PostgreSQL service role is normally the better design. Interactive MFA enforcement is intended for user authentication, not workload identities.

If the original thread already establishes that the token is valid, the principal mapping is correct, and changing only isMfa changes the outcome, I wouldn't keep recreating roles or adjusting Conditional Access policies without evidence.

At that point, this needs a Microsoft support case under Azure Database for PostgreSQL Flexible Server, with the PostgreSQL version, region, exact server authentication error, UTC timestamp, sanitized token claims, and the results of the psql comparison. Ask engineering to confirm which claim representation the deployed MFA validator actually accepts and whether there's a known compatibility issue. The available documentation doesn't establish that a separate top-level mfa claim is required, so I wouldn't present that as the solution without confirmation from the PostgreSQL engineering team.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer