Can a web-app be deployed using a client certificate instead of client secret if end-users are using PIV cards for authentication?

Question

We have end-users who authenticate to an enterprise application hosted in Azure using either PIV (Personal Identity Verification) cards or Windows Hello for Business (WHfB). When the web application is configured to use a shared client secret for authentication, both PIV and WHfB users are able to successfully authenticate and access the application without issue.

However, when we modify the application to use a client certificate (SSL certificate) instead of the shared secret, PIV users are no longer able to access the application, while WHfB and other non-PIV users continue to authenticate successfully.

Upon investigation, I observed that the redirect URI behavior changes depending on the authentication configuration. When using a shared secret, the application redirect URI is /auth/microsoft/callback. In contrast, when using a client certificate, the redirect URI changes to /auth/redirect.

PIV users encountering the certificate-based configuration receive the following error from Azure AD: AADSTS299266 — "Blob grant token received with wrong issuer type."

Answer 1

Hi Tom Bevins,

Yes, web-apps can be deployed using a client certificate if end-users are using PIV cards.

However, if you're still seeing the error like AADSTS299266 – Blob grant token received with wrong issuer type, it's likely due to a certificate issuer mismatch.

Note: PIV login is a form of certificate-based authentication for the user. When both the user and the app are authenticating using certificates, Azure AD applies more strict certificate validation logic on both ends.

When the app and user are authenticating using certificates Azure AD checks whether the certificate used by the user for PIV card and the certificate used by the app both come from trusted certificate authorities (CAs) If either of them comes from an unexpected or untrusted CA, Azure AD blocks the authentication, in your case PIV CA.

To fix this, you need to add the PIV certificate’s root and intermediate CAs to your Entra ID tenant’s trusted certificate list.

Check the PIV issuer’s root and intermediate CA and export the full certificate chain from a working PIV card (root + intermediate certs).

Upload the PIV certificate chain to Entra ID at Microsoft Entra Admin Center(https://entra.microsoft.com/) -> Certificate Authorities.

Upload the .cer files for both the root CA and intermediate CA(s). This makes Azure AD recognize and trust the PIV card as a valid identity source.

Refer: How to configure Microsoft Entra certificate-based authentication - Microsoft Entra ID | Microsoft Learn

• Ensure the web app’s client certificate is trusted The app's client cert must also come from a trusted CA, preferably the same root as PIV or one uploaded to Entra ID.
• Better to have same issuers of PIV and Client app from CAs because Entra ID expects both certificates of user and app to be from trusted and expected issuers. any mismatched issuers can trigger errors like AADSTS299266 – Blob grant token received with wrong issuer type.
• Also make sure your authority URL is right.

Hope this helps!

If this answers your query, do click Accept Answer and Yes for was this answer helpful, which may help members with similar questions.

If you have any other questions or are still experiencing issues, feel free to ask in the "comments" section, and will be happy to help.

Answer 2

Based on your recommendation, we revisited both our enterprise Certificate Authority (CA) and PIV certificate issuance process, as well as the configuration of our Azure and enterprise applications.

We verified that the root and intermediate CA certificates were correctly configured in Azure, and we successfully authenticated using PIV and PIN credentials to both the Azure Portal and https://myaccount.microsoft.com. During this process, we examined the SSL certificate used for server-to-Azure authentication and discovered it was self-signed.

We then regenerated the SSL certificate, this time ensuring it was signed by the same enterprise CA that issues our PIV certificates. Despite this, we continued to encounter the same error code.

As part of further troubleshooting, I reviewed the authentication endpoint to which the msal-node library was redirecting. It was pointing to {tenant_name}.ciamlogin.com. For testing purposes, I hardcoded the AUTHORITY to use https://login.microsoftonline.com/{TENANT_ID}, which resolved the issue. After making this change, all users—whether authenticating via PIV/PIN or Windows Hello For Business—were able to access the application without issue.

While this workaround yields positive results, I’m uncertain about the long-term implications. Specifically, I'm concerned whether hardcoding the authority in this way may restrict support for additional authentication methods in the future or introduce other limitations.