Technical note: don't forget to URL encode your query params!
Greetings space developers!
Teams Tech Co and BBS have been looking into a small flutter of errors that we started seeing this morning after a new deployment of the SSO. During this deployment, we changed a few details about the structure of SSOv1 access tokens and there's been some interesting fallout.
The short version is that prior to today, v1 access tokens have always consisted of characters that look the same regardless of whether the token is URL encoded or not. After today, that is no longer the case. The tokens are now also slightly longer than they were yesterday.
We are seeing a small number of applications that are using ESI's query parameter token feature to make their requests but are not URL encoding their tokens. This results in tokens that are invalid being transmitted to ESI, which results in a failed authorization. We are also seeing some applications are truncating the now slightly longer tokens before transmission, which results in similar authorization errors.
It's important to always URL encode your query parameters before dispatching them to ensure that they do not become malformed during transmission. In the short term, we have elected to monkey-patch the sso-backend to be tolerant of the specific issue with + symbols being converted into spaces that several applications are seeing today, but we do not guarantee this convenience beyond Nov 1st, so please implement URL encoding prior to this date.
Unfortunately, there is nothing we can do to help applications that are truncating their tokens before transmission. If your application is doing this you'll need to update it to remove the token length assumption ASAP. We suspect that there are a few DB's around with VARCHAR(x) assumptions encoded into their token table schema.
Carry on!
Tech Co & BBS