I have problems in my own app using esi since 3 days. I use code base @ esi-docs example, to validate jwk.
Unfortunately i have raising except in 58 line:
The JWT signature was invalid: Invalid audience
I dont know, what what is wrong, app to that time working without problems.
Does anything is change in ESI?
Does anyone same problems too?
CCP added a new “aud” claim to the JWT. We didn’t get the memo.
Wanting to point this out in case others come across it. While the communication/heads up could have been better, adding this claim is not a breaking change in of itself. The fact that apps broke because of this is more indicative of a bug in the application in that they were validating more than they should have been and it just happened to work.
Use this example to take some time to go thru and ensure whatever library you’re using to validate your JWTs does not have any other validations enabled that EVE’s JWT token is not using. For example, if using GitHub - mpdavis/python-jose: A JOSE implementation in Python, and since there was no aud claim in the token, that part of the validation should have been disabled via the verify_aud: False option. That would have totally prevented this from becoming an issue. A follow up could then have enabled it while also setting the expected value.
4.1.3. “aud” (Audience) Claim The “aud” (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the “aud” claim when this claim is present, then the JWT MUST be rejected. In the general case, the “aud” value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the “aud” value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.
If the principal processing the claim does not identify itself with a value in the “aud” claim when this claim is present, then the JWT MUST be rejected.
Correct. The validation libraries are doing the right thing in that the JWT token has an aud claim, but the decoding logic was not provided a valid audience value, so it was rejected. HOWEVER, the RFC says that Use of this claim is OPTIONAL., so validation should have been turned off in the first place since you cannot validate a value that is not present. I.e.
when this claim is present
this part in the spec.
So… do what the example code does then? esi-docs/validate_jwt.py at master · esi/esi-docs · GitHub
The example code should have did like:
return jwt.decode(
jwt_token,
jwk_set,
algorithms=jwk_set["alg"],
issuer="login.eveonline.com",
options={"verify_aud": False}
)
But it was missed, so was also affected by this. Add new audience claim to JWT code example and docs by ErikKalkoken · Pull Request #69 · esi/esi-docs · GitHub was created to address it by providing the expected audience claim now that the JWT is using it.
This pull request doesn’t ignore the “aud” claim as you say it “should”, it validates it.
You also didn’t review the code by the looks of it as per Add new audience claim to JWT code example and docs by ErikKalkoken · Pull Request #69 · esi/esi-docs · GitHub
Right it SHOULD have ignored it when there was no aud claim in the JWT. However now that it is, it’s proper to validate it, as you pointed out earlier. Which this PR is doing.
I know, I don’t really know python so I didn’t want to give my approval for something I’m not fully familiar with.
Fair enough, IETF really should write clearer. When you read something in their RFC’s and then think you have it clear, you always come up against another paragraph or sentence which just fogs the clarity.
That example code (bad example) from CCP sat there for years without it being highlighted (unless there was an open ticket for it I missed).
Also, a communication heads up on a developer communication RSS feed (not behind a private company signup system but direct from CCP open) would have helped. It seems a discussion on “Slack” was done about it, whatever that private third party system is that I don’t and never will use. See Can't add character: "The JWT signature was invalid: Invalid audience" · Issue #2421 · pyfa-org/Pyfa · GitHub
We need open communication from CCP. I don’t want to have to sign up to another private company’s system to get developer notifications.
If CCP are using Slack, that means me as a developer won’t be getting communications that are important and possibly breaking updates.
Is there an active developer RSS news stream I can pull? Is there an open IRC server channel (or something) run by CCP for developers?
This Developer Blog was updated last in 2021-10-07 13:06
The amount of people affect by this clearly show this was a breaking change.
There are standards and there is reality, only considering the former isn’t a good way to evaluate if something is really a breaking change that should be communicated in advance.
Since we are the “costumers” it’s also worth keeping in mind that this is just a hobby for some of us.
At least that is my point of view…
Especialy given the Python code example from CCP also broke on adding a “non breaking” claim, didn’t follow the RFC spec for an ommitted “aud” claim. The apps that broke, followed the leaders example.
A hobby that we pay for. Obtaining a developer key is not free, we have to have one payment at least on record. We are bread and butter for CCP, we pay to play the game too (mostly), we also fill in the gaps and add value around their game to other paying players. In many ways, we are cheap labour.
.
Thanks for tips and information, i just add audience="EVE Online" into code.
I guess its not something i ever did then because mine didn’t break afaik >.<
But i also don’t think i wasted cycles validating the JWT because i just assume if its from CCP its valid and its not accessing protected data so its mostly a moot point for my use case
But i already have a real one
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
