Access_token malformed?

Authentication
1

We have an internal system that uses the FreeAgent API to pull down some data. It has been running fine for over 3 years now and today, after logging in and approving the app request and trying to make a call against the FreeAgent API we get a InternalServer error (our system).

On closer inspection it’s failing on extracting the access_token from the FAAccessToken. Looking at the token, it doesn’t seem to adhere to the standards of access_tokens because it has 2 equal signs in it meaning the first one gets URL encoded but 2nd one doesn’t.

The access_token we get back looks like this:

{"access_token":"mc==UH6-xxxxx-xxxxxxxxx_xxxxxxxxxxxxxx_","token_type":"bearer","expires_in":3600,"refresh_token":"xxxx","refresh_token_expires_in":631139040}

In C# when I call Request.Headers.GetCookies() and access the FAAccessToken value I get:
"{\"access_token\":\"mc"

I’m not sure if something has changed on the API end or what has happened but even looking at the announcement back from May 2020 about the API change, the access_token in the example looks like this:

"access_token":"2YotnFZFEjr1zCsicMWpAA"

Can someone help me figure out what is going on?

2

Hi there!

You are correct. The access token has changed a tiny bit. We’ve changed the first four bytes to contain some originating information. The length should remain the same, and all of the characters used should be url safe. I do apologise for the issues you are having.

The change recently modified the first four bytes of the token to include characters from the BASE64 alphabet as well as padding characters (one or more “=”). However, access tokens should always be treated as strings and used as a string identifier.

The access token response is

{
 "access_token":"A5c=otnFZFEjr1zCsicMWpAA",
 "token_type":"bearer",
 "expires_in":3600,
 "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "refresh_token_expires_in":777600
}

And the access token encoded in a JSON key-value pair. Ideally, with whatever implementation of a JSON parser you are using, you just look up the key “access_token” and accept and store the value of that key. I hope that helps.

Cheers

Phil Muldoon
Senior Engineer, API/Core Services

3

Thanks for the quick response. At least I know it’s nothing from our side that has changed.

I know what is happening now and have fixed the problem. When I get the auth data back from the authorisation call I store it in a cookie to then use for future calls and the problem was I wasn’t UrlEncoding the data of that cookie.

I’ve added the encoding and now it works correctly.

Thanks for your help Phil.

4

Hi there!

On reviewing RFC 6750 your point illuminated that some systems do Base64 encode the access token to contains secrets. FreeAgent’s API does not do that but I see how it could potentially cause problems. Even though we don’t encode secrets in the access token, I’ve changed the algorithm to use “~” characters as padding in the first four bytes.

Thank you for the report as it helped us improve how access tokens are generated.

Cheers

Phil

5

No worries, glad to be of help and thank you again for the assistance.