What causes AADSTS50048?

Client assertion JWT built with sub or iss set to the tenant ID, object ID, or user principal name instead of the application (client) ID. sub and iss claims pointing to two different app registrations (e.g. assertion signed for app A but sent to token endpoint for app B). Federated identity credential (workload identity federation) configured with a subject identifier that doesn't match the external token's sub claim. Certificate used to sign the assertion belongs to a different app registration than the one in the iss/sub claims. Custom token-generation code (MSAL ClientAssertion, ADAL, or hand-rolled JWT) with a hardcoded or stale client ID after an app re-registration

How do I fix AADSTS50048?

Decode the failing client assertion JWT (jwt.ms) and verify both sub and iss equal the Application (client) ID of the app registration in Entra ID — not the tenant ID, object ID, or service principal ID. In Entra admin center → App registrations → your app → Certificates & secrets, confirm the certificate thumbprint (x5t header in the JWT) is uploaded on this exact app registration. If using workload identity federation (GitHub Actions, Kubernetes, ADO), open the Federated credentials tab and verify the Subject identifier exactly matches the sub claim in the incoming external token (case-sensitive, no trailing slash). If using MSAL with ConfidentialClientApplication, ensure WithClientAssertion / WithCertificate is called on a builder initialized with the same client_id that issued the certificate. After fixing, request a new token (cached tokens won't refresh until expiry) and re-run the Power BI / ADF / Fabric service principal flow

Low severityauthentication

Power BI Error:
AADSTS50048

What does this error mean?

The Subject (sub) claim in the client assertion JWT does not match the Issuer (iss) claim required by Entra ID.

Common causes

1Client assertion JWT built with sub or iss set to the tenant ID, object ID, or user principal name instead of the application (client) ID
2sub and iss claims pointing to two different app registrations (e.g. assertion signed for app A but sent to token endpoint for app B)
3Federated identity credential (workload identity federation) configured with a subject identifier that doesn't match the external token's sub claim
4Certificate used to sign the assertion belongs to a different app registration than the one in the iss/sub claims
5Custom token-generation code (MSAL ClientAssertion, ADAL, or hand-rolled JWT) with a hardcoded or stale client ID after an app re-registration

How to fix it

1Decode the failing client assertion JWT (jwt.ms) and verify both sub and iss equal the Application (client) ID of the app registration in Entra ID — not the tenant ID, object ID, or service principal ID
2In Entra admin center → App registrations → your app → Certificates & secrets, confirm the certificate thumbprint (x5t header in the JWT) is uploaded on this exact app registration
3If using workload identity federation (GitHub Actions, Kubernetes, ADO), open the Federated credentials tab and verify the Subject identifier exactly matches the sub claim in the incoming external token (case-sensitive, no trailing slash)
4If using MSAL with ConfidentialClientApplication, ensure WithClientAssertion / WithCertificate is called on a builder initialized with the same client_id that issued the certificate
5After fixing, request a new token (cached tokens won't refresh until expiry) and re-run the Power BI / ADF / Fabric service principal flow

Frequently asked questions

What does AADSTS50048 mean?

Subject mismatches Issuer claim in the client assertion. Contact the tenant admin.

How do I fix this error?

Check your application registration, token configuration, and user permissions in the Azure portal. Review Conditional Access policies if the error is policy-related.

Source · learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes#aadsts-error-codes