Closed TomRichter closed 2 years ago
+1 (on MacOS 12.3 (21E230))
Looks like it's due to an unannounced change from today, via #sso
in Tweetfleet Slack:
Eingang Vulpine
@CCP Ghostrider
JWT Validation Broken
It looks like you guys might have changed something this afternoon. Anyone that has applications that validate JWTs as part of the auth flow are failing to authenticate with errors like "The JWT signature was invalid: Invalid audience" My logs are clogged with these errors starting at 16:00 GMT, but anecdotal evidence suggests it started earlier than that, but was still fine around 10:30 GMT this morning. Applications that don't do the right thing by validating the JWT work fine for logging in via the SSO.
CCP Ghostrider
We added the “aud” claim (it wasn’t there before). Either set the expected aud value to “EVE Online” or disable audience validation. Adding claims isn’t a breaking change.
Erik Kalkolken :nerd_face:
Yes, adding new claim in general is not a breaking change, but going from not using aud to using aud is a breaking change.
e.g. your code example for verifying JWTs will no longer work, because you need to specify the aud value . https://github.com/esi/esi-docs/blob/master/examples/python/sso/validate_jwt.py#L52
algorithms=jwk_set["alg"],
CCP Ghostrider
Then why did it work without one? Either it should try to validate the aud claim or not and if so, error if its missing instead of just skipping it?
Hiro Logos
From the JWT spec https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3
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.
So anyone not specifying an “aud” when validating the JWT, if they're following the spec, MUST reject all JWTs. And since no one could have known what value to expect ahead of time, it is a breaking change
Golden Gnu
Yes, everyone who is correctly validating the JWT are now rejecting all tokens, so, while it's possible to ignore aud, had it been announced in advance, that is not something anyone could have guessed they needed to do, without prior notice.
CCP has updated their example for handling the "aud" claim. https://github.com/esi/esi-docs/pull/69
Bug Report
When adding a character in SSO Character Management, the process fails due to "invalid audience" in JWT.
This happens with a clean install of release v2.40.0, even after deleting all settings files. Used to work in older versions but not sure how far back since I've been AFK a few months.
Logs included below but seem useless for this. They only mention starting and stopping the internal web server -- nothing about which character was chosen or even receiving a failed attempt.
Local time zone is UTC-5.
Expected behavior:
Adding a character should complete with a success message in browser and a new or updated character in pyfa.
Actual behavior:
After logging into EVE SSO and picking a character, the browser displays the following error and no character is added:
Detailed steps to reproduce:
%userprofile%/.pyfa
to completely clear settings.Character > Manage ESI Characters > Add Character
.Release or development git branch? Please note the release version or commit hash:
Downloaded from release branch via GitHub Releases.
pyfa Version v2.40.0 EVE Data Version: 2013787 (2022-03-08 16:11:05)
Operating system and version (eg: Windows 10, OS X 10.9, OS X 10.11, Ubuntu 16.10):
Other relevant information: