Action required (Potentially)

Security and privacy is always a concern at Cloudbeds, and the time has come to update our OAuth library to the industry and technology standards.

Starting June 1st, 2020 we’ll be using the JWT (JSON Web Token) standard for our OAuth tokens. If you’re wondering, it’s pronounced “jot”.

JWT is an advanced and extremely secure standard that defines a set of “claims” that can be transferred across different entities to describe an agent’s identity and authenticity. Applying the concept to our API, it means the access token will carry information about who authenticated the session, for which scopes, for which client.

Every API request begins with this same step: it needs to identify which API client it is, which Cloudbeds user it’s impersonating, which scopes were given access to it. If this information is available on the token, this step becomes much quicker, since we’ll do less I/O, we’ll reduce DB usage, and responses will be generated quicker.

Are you're worried that anyone could inject information into it to try to impersonate other API clients, or another Cloudbeds user, or even grant itself access to other scopes? Fret not! The JWT standard allows the tokens to be encrypted, which is what we’re doing here.

Since now the tokens carry information, and because the amount of information can change (how many scopes were assigned to an API session, for example), their size will significantly increase. Currently, our tokens (authorization code, access token and refresh token) are 40 characters long. Depending on the encoded values, the token size will average from 600 to 1000 characters.

This means that you’re expected to store up to 2000 chars, just to be safe, and since we’re here, let’s round it up to 2048 characters (2kb). Depending on how your database is set up this could be a critical adjustment therefore immediate action is required on your part.

A small change in how our OAuth tokens are handled

We've made a small adjustment in how we handle the OAuth tokens. Likely, this won't affect you at all; however, we'd like you to be aware of this flow.

Once you submit a request to issue a new access_token you won’t be able to use the access_token you had before. You must use a new one.

In case you didn't save a new access_token you can still use refresh_token to get it again but only until you start using new acces_token.

Here’s an example

• You have the access_token0/refresh_token0 pair.
• You submit a request for a new access token by using refresh_token0 and Cloudbeds authorization server issues a new pair access_token1/refresh_token1.
• From this moment on, all your requests to get resources with access_token0 will fail.
• But if you weren't able to save pair access_token1/refresh_token1 you can use refresh_token0 to acquire those tokens again.
• As soon as you requested a resource with access_token1 you can't use refresh_token0 anymore.