BUG : Unexpected JWT Validation Exception - IDX10205: Issuer validation failed #10532

CCBPMDev · 2024-10-17T12:25:46Z

Recent Azure Functions Deployment is appearing to perform Token Validation resulting in "IDX10205: Issuer validation failed" log level message. JWT auth is not configured or expected. Earlier runtime version 4.35 did not exhibit this behaviour. Redeploying of the same code (no issue) with runtime 4.35, new deployment defaults to latest runtime 4.136 will produced this error.

Azure App Service with EasyAuth on / off does not change this behavour.

I should not experience JWT validation issues.

Runtime Stack: DOTNET-ISOLATED|8.0
Runtime/SDK Version: 4.1036.2.2
OS: Linux
Plan: Premium V2
Region: WEU & UKS

Error : IDX10205: Issuer validation failed.
Exception Type : Microsoft.IdentityModel.Tokens.SecurityTokenInvalidIssuerException

Microsoft.IdentityModel.Tokens.SecurityTokenInvalidIssuerException:
at Microsoft.Extensions.DependencyInjection.ScriptJwtBearerExtensions.IssuerValidator (Microsoft.Azure.WebJobs.Script.WebHost, Version=4.1036.0.0, Culture=neutral, PublicKeyToken=null: /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Jwt/ScriptJwtBearerExtensions.cs:152)
at Microsoft.IdentityModel.Tokens.Validators+d__7.MoveNext (Microsoft.IdentityModel.Tokens, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.IdentityModel.Tokens.Validators.ValidateIssuer (Microsoft.IdentityModel.Tokens, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.IdentityModel.Tokens.InternalValidators.ValidateAfterSignatureFailed (Microsoft.IdentityModel.Tokens, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateSignature (System.IdentityModel.Tokens.Jwt, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateSignatureAndIssuerSecurityKey (System.IdentityModel.Tokens.Jwt, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateJWS (System.IdentityModel.Tokens.Jwt, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.ValidateToken (System.IdentityModel.Tokens.Jwt, Version=6.35.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35)
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler+d__6.MoveNext (Microsoft.AspNetCore.Authentication.JwtBearer, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)

Packages used.

<PackageReference Include="AutoMapper" Version="13.0.1" />
<PackageReference Include="FluentResults" Version="3.16.0" />
<PackageReference Include="FluentResults.Extensions.AspNetCore" Version="0.1.0" />
<PackageReference Include="FluentValidation.DependencyInjectionExtensions" Version="11.10.0" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.23.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.4.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.3.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.OpenApi" Version="1.5.1" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1" />
<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="8.0.1" />

Function Header

public async Task Run
(
[HttpTrigger(AuthorizationLevel.Anonymous, "POST", Route = "Test/Test")]
HttpRequest httpRequest
) => ...

The text was updated successfully, but these errors were encountered:

TheAzureGuy · 2024-10-29T21:43:16Z

Running into exactly the same issue with the above mentioned runtime version. Please advise on possible resolution.

The dependencies are as follows:

<PackageReference Include="AspNetCore.HealthChecks.CosmosDb" Version="8.0.1" />
<PackageReference Include="Azure.Storage.Blobs" Version="12.22.2" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Extensions.Options" Version="8.0.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.23.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.3.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ServiceBus" Version="5.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.4.0" />
<PackageReference Include="Microsoft.Extensions.Diagnostics.HealthChecks" Version="8.0.10" />`

molivetree · 2024-10-30T10:45:06Z

Also running into the same issue.
The dependencies are the following:

Fazer01 · 2024-10-30T13:04:35Z

Hi there!

We also can confirm the issue. Using .NET8 Isolated with the following Functions Runtime version: 4.1036.3.23284

Some of our 'old' functions using .NET6 in process are on a very different runtime version: 4.636.0.23246 where the issue doesn't manifest itself.
Perhaps only the newer runtime version with .NET8 Isolated is causing this issue?

Since this morning we are facing this 'exception' in Application Insights:

jimpudar · 2024-10-30T21:13:10Z

I am also seeing this issue in a Function App on .NET 8 Isolated runtime version 4.1036.2.2 that started yesterday.

VIRY-tivoli · 2024-10-31T10:31:47Z

We are also experiencing this issue on .net 8 isolated. Started yesterday (2024-10-30T05:07:32.0527717Z):

mjacksonjjk · 2024-10-31T13:37:28Z

We are also seeing the same issue. For added details, we have the same the identical .NET8-Isolated build artifact deployed to 2 function app instances, one of which is still on an older runtime version:

Runtime version 4.36.0.23246 -> No exceptions
Runtime version 4.1036.3.23284 -> Exceptions

Shuvajyoti · 2024-11-01T10:29:27Z

Hi all, we are also facing this for out .Net 8 isolated function app.
Our error message is - 'IDX10205: Issuer validation failed.'
Functions sdk version is - azurefunctions: 4.1036.3.23284

Is there are any resolution for this ?

MaxMommersteeg · 2024-11-01T10:53:51Z

Same here. Runtime version '4.1036.3.23284' is causing the 'IDX10205: Issuer validation failed.' errors.

sjhawke · 2024-11-01T11:04:26Z

We have found this to be a problem with the AAD Graph to MS Graph transition accidentally breaking the contract in OAuth2 by changing the issuer.

See here:
AAD Graph Manifest Deprecation

The way Enterprise Application manifest is processed for the App registration for the hosted function means that the client will default to using the graph.microsoft.com token issuer rather than the sts.windows.net issuer if either apiAccessTokenAcceptedVersion or requestedAccessTokenVersion are NOT SET.

This is fixable by force setting the apiAccessTokenAcceptedVersion or requestedAccessTokenVersion key to the correct version in the api entity in the app registration in Entra.

for sts.windows.net use 1, for graph.microsoft.com use 2.

Make sure this is matched in your Easy Auth configuration in App Service.

The below snippet forces the value of the issuer to 1, which was the original implicit default.

    $body = '{\"api\":{\"requestedAccessTokenVersion\":1}}'
    
    & az rest --method PATCH `
                --url "https://graph.microsoft.com/v1.0/applications/$objectId" `
                --headers Content-Type=application/json `
                --body ($body)

Can post more detail on request - but this is our good summary.

TheAzureGuy · 2024-11-01T15:04:12Z

@sjhawke thank you for the helpful response.

My app does not use Easy Auth. It is configured with a user-assigned managed identity. What would $objectId be in this case?

sjhawke · 2024-11-01T15:22:18Z

@sjhawke thank you for the helpful response.

My app does not use Easy Auth. It is configured with a user-assigned managed identity. What would $objectId be in this case?

Hi - it would be the application id in AAD that is assigned to your service. Check your configuration for the appId in your directory and look it up to find the objectId. It is the .id field in the record and should be a guid. Bear in mind that your managed identity is not the same as an application in AAD/Entra. MSID/User assigned Id is a service principal which is a different kind of entity in the directory and is usually a client, not a service.

Note: This has not fully resolved our issue.

TheAzureGuy · 2024-11-01T19:41:20Z

We tried updating requestedAccessTokenVersion to 1 and it was not successful. The error message indicates that this property cannot have any values other than 2.

mkeinemans · 2024-11-04T14:15:59Z

We have been having this issue as well, this started 2 weeks ago in our East US region but has now spread to our other regions as well.

They are all running version 4.1036.3.23284. I forcefully set the FUNCTIONS_EXTENSION_VERSION to 4.36.0.23246 (without the ~). This has fixed the issue for now.

Hopefully this issue will be resolved.

alefranz · 2024-11-04T15:30:16Z

I think there is a good chance this is caused by the EasyAuth update in #10490

any chance this can be investigated @fabiocav as a potential breaking change? Thank you!

fabiocav · 2024-11-04T17:30:20Z

Thank you all for reporting. We're actively looking at this and will provide updates as more information is available.

fabiocav · 2024-11-04T19:07:14Z

If you're experiencing this issue, can you please share an invocation ID, time range when the problem occurred and the region your application is running in?

Thank you!

cultpodcasts · 2024-11-04T19:36:18Z

If you're experiencing this issue, can you please share an invocation ID, time range when the problem occurred and the region your application is running in?

053cfb15-6bad-4466-bf02-51bd29f7d05c - 04/11/2024, 19:32:24.7446117 (UTC/GMT) - UK South

mkeinemans · 2024-11-05T08:27:39Z

I just noticed that our Exception is not exactly the same as mentioned in this issue. We are getting 'Microsoft.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException' exceptions.

Invocation Id 'e0ca6f5a-41ed-4b4e-97a3-36d9358dc120' in West Europe 11/5/2024, 8:19:43.1806979 AM.

Do you want me to create a separate issue for this since it is a different Exception?

hKaspy · 2024-11-05T09:07:44Z

Hi! Having the same problem on Azure functions for Node.

SDK version 4.1036.3.23284

Invocation ID 1b024620d0dc4d61bebf92e6a1b710e9, West Europe on 2024-11-05T07:48:12.8156859Z.

Fortunately the exception is only logged and doesn't crash the app for now...

alefranz · 2024-11-06T12:02:37Z

If you're experiencing this issue, can you please share an invocation ID, time range when the problem occurred and the region your application is running in?

Thank you!

Thanks for jumping into this!
Info in TrackingID#2410290050001869

jviau · 2024-11-06T21:26:06Z

Want to share an update.

We have so far identified this to be only a change in logging with the 4.10xx versions of the host. Specifically, these exceptions and errors do occur in previous versions (as verified by tests). However, previously they were never sent to customer logs.

We will continue to look into this to see if we can avoid emitting the error log.

Mitigation

For the time being, you can filter this error log via a log filter for Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler, with a level of Warning. This can be done in either host.json or as an app setting.

Via host.json:

{
  "Logging": {
    "ApplicationInsights": {
        "LogLevel": {
            "Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler": "Warning"
        }
    }
  }
}

via app setting:

Key: Logging__ApplicationInsights__LogLevel__Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler
Value: Warning

fabiocav · 2024-11-07T02:52:30Z

I just noticed that our Exception is not exactly the same as mentioned in this issue. We are getting 'Microsoft.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException' exceptions.

Invocation Id 'e0ca6f5a-41ed-4b4e-97a3-36d9358dc120' in West Europe 11/5/2024, 8:19:43.1806979 AM.

Do you want me to create a separate issue for this since it is a different Exception?

@mkeinemans yes please. If you can open a separate issue and capture the details there, we'll be able to look at your specific problem.

Thanks!

AntonDykyi · 2024-11-08T14:04:10Z

Want to share an update.

We have so far identified this to be only a change in logging with the 4.10xx versions of the host. Specifically, these exceptions and errors do occur in previous versions (as verified by tests). However, previously they were never sent to customer logs.

We will continue to look into this to see if we can avoid emitting the error log.

Mitigation

For the time being, you can filter this error log via a log filter for Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler, with a level of Warning. This can be done in either host.json or as an app setting.

{
"Logging": {
"ApplicationInsights": {
"LogLevel": {
"Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler": "Warning"
}
}
}
}

@jviau It sounds like these errors were not meant to appear on the customer's side. Does it have something to do with something like an upcoming upgrade to V2 of access tokens as default across the platform or the deprecation of AAD Graph and some internal information gathering MS is doing in the background? The tokens are still valid, but the issuer differs between two versions causing the validation logic to return the exception.
"issuer": "https://login.microsoftonline.com/{tenantid}/v2.0 vs "issuer": "https://sts.windows.net/{tenantid}/".

dggsax · 2024-11-13T21:42:33Z

Want to share an update.

We have so far identified this to be only a change in logging with the 4.10xx versions of the host. Specifically, these exceptions and errors do occur in previous versions (as verified by tests). However, previously they were never sent to customer logs.

We will continue to look into this to see if we can avoid emitting the error log.

Mitigation

For the time being, you can filter this error log via a log filter for Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler, with a level of Warning. This can be done in either host.json or as an app setting.

Via host.json:

{
"Logging": {
"ApplicationInsights": {
"LogLevel": {
"Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler": "Warning"
}
}
}
}
via app setting:
Key: Logging__ApplicationInsights__LogLevel__Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler
Value: Warning

Just wanted to check, but when I try to set log level at logging.applicationInsights.loglevel in our host.json file I get the warning: "Property logLevel is not allowed", did you mean for the setting to be defined at logging.logLevel, or can we ignore the warning about it not being allowed at the originally specified place?

Thanks!

jviau · 2024-11-13T22:26:15Z

@dggsax I recommend trying with the logging.applicationInsights.logLevel section first, then trying logging.logLevel after if it doesn't address this.

mejiaej · 2025-01-27T19:16:52Z

I'm getting this error in 2025, is this an issue still?

miguelperedozurcher-neste · 2025-01-29T11:04:32Z

Same here! Started today!

alefranz · 2025-01-29T18:17:40Z

it will be fixed with the next runtime update, at some point before end of Feb, according to the comment in the fix

#10617 (comment)

microsoft-github-policy-service bot added the Needs: Triage (Functions) label Oct 17, 2024

jviau mentioned this issue Nov 11, 2024

Scope ScriptJwtBearerHandler logs to system-only #10617

Merged

9 tasks

satvu mentioned this issue Nov 12, 2024

[Bug] IDX10503: Signature validation failed. Token does not have a kid. #10621

Closed

jviau closed this as completed in #10617 Nov 15, 2024

microsoft-github-policy-service bot removed the Needs: Triage (Functions) label Nov 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BUG : Unexpected JWT Validation Exception - IDX10205: Issuer validation failed #10532

BUG : Unexpected JWT Validation Exception - IDX10205: Issuer validation failed #10532

CCBPMDev commented Oct 17, 2024

TheAzureGuy commented Oct 29, 2024 •

edited

Loading

molivetree commented Oct 30, 2024

Fazer01 commented Oct 30, 2024 •

edited

Loading

jimpudar commented Oct 30, 2024

VIRY-tivoli commented Oct 31, 2024

mjacksonjjk commented Oct 31, 2024 •

edited

Loading

Shuvajyoti commented Nov 1, 2024

MaxMommersteeg commented Nov 1, 2024

sjhawke commented Nov 1, 2024

TheAzureGuy commented Nov 1, 2024

sjhawke commented Nov 1, 2024 •

edited

Loading

TheAzureGuy commented Nov 1, 2024

mkeinemans commented Nov 4, 2024

alefranz commented Nov 4, 2024

fabiocav commented Nov 4, 2024

fabiocav commented Nov 4, 2024

cultpodcasts commented Nov 4, 2024

mkeinemans commented Nov 5, 2024

hKaspy commented Nov 5, 2024

alefranz commented Nov 6, 2024

jviau commented Nov 6, 2024 •

edited

Loading

fabiocav commented Nov 7, 2024

AntonDykyi commented Nov 8, 2024

Mitigation

dggsax commented Nov 13, 2024

Mitigation

jviau commented Nov 13, 2024

mejiaej commented Jan 27, 2025

miguelperedozurcher-neste commented Jan 29, 2025

alefranz commented Jan 29, 2025

BUG : Unexpected JWT Validation Exception - IDX10205: Issuer validation failed #10532

BUG : Unexpected JWT Validation Exception - IDX10205: Issuer validation failed #10532

Comments

CCBPMDev commented Oct 17, 2024

TheAzureGuy commented Oct 29, 2024 • edited Loading

molivetree commented Oct 30, 2024

Fazer01 commented Oct 30, 2024 • edited Loading

jimpudar commented Oct 30, 2024

VIRY-tivoli commented Oct 31, 2024

mjacksonjjk commented Oct 31, 2024 • edited Loading

Shuvajyoti commented Nov 1, 2024

MaxMommersteeg commented Nov 1, 2024

sjhawke commented Nov 1, 2024

TheAzureGuy commented Nov 1, 2024

sjhawke commented Nov 1, 2024 • edited Loading

TheAzureGuy commented Nov 1, 2024

mkeinemans commented Nov 4, 2024

alefranz commented Nov 4, 2024

fabiocav commented Nov 4, 2024

fabiocav commented Nov 4, 2024

cultpodcasts commented Nov 4, 2024

mkeinemans commented Nov 5, 2024

hKaspy commented Nov 5, 2024

alefranz commented Nov 6, 2024

jviau commented Nov 6, 2024 • edited Loading

Mitigation

fabiocav commented Nov 7, 2024

AntonDykyi commented Nov 8, 2024

Mitigation

dggsax commented Nov 13, 2024

Mitigation

jviau commented Nov 13, 2024

mejiaej commented Jan 27, 2025

miguelperedozurcher-neste commented Jan 29, 2025

alefranz commented Jan 29, 2025

TheAzureGuy commented Oct 29, 2024 •

edited

Loading

Fazer01 commented Oct 30, 2024 •

edited

Loading

mjacksonjjk commented Oct 31, 2024 •

edited

Loading

sjhawke commented Nov 1, 2024 •

edited

Loading

jviau commented Nov 6, 2024 •

edited

Loading