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.
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).
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.