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

Question

Problem description

I am experiencing an authentication issue with my Azure Database for PostgreSQL flexible server. When using Microsoft Entra ID for login, roles configured with isMfa = true are rejecting the login with SQLSTATE 28000, even though the token I present includes 'mfa' in the amr claim. I need help understanding why this discrepancy occurs and how to resolve it.

Environment

Azure Database for PostgreSQL flexible server; Authentication: Microsoft Entra ID; Client: Azure-hosted application in container; Driver: node-postgres (pg) 8.23.1 on Node.js 22; Region: not specified in case information.

What I've already tried

The issue has been persistent since the start. I have verified that the token used for login contains 'mfa' in the amr claim, and the server was not shown as unavailable in Azure Portal Resource Health at the time. No retries or specific configuration changes have been mentioned or documented in the case.

Current status

Currently, the authentication is still being rejected with SQLSTATE 28000 for roles with isMfa = true, despite the token indicating MFA in amr. I am seeking clarification on whether the token must contain a top-level 'mfa' claim for this scenario, and how to configure Entra ID or the token request to ensure successful authentication.

This is the same issue as question 6046105, where the claim list and log lines are already documented.

Answer 1

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