Each response from Cloud CMS provides two tokens: an access token and a refresh token.
The access token is the one that you need to attach to every API call. It gets passed through the Authorization header as "bearer <accessToken>" and Cloud CMS uses this to identify who the authenticated user is (and thus, what resources they have access to and so forth).
By default, the access token has a lifespan of 24 hours. After that period of time, it is no longer valid and any requests will come back with a 401 and a JSON payload that indicates that the access token has expired.
At that point, you either have to re-authenticate (getting a new access token) or you can simply hand over your refresh token to get a new access token. The latter is preferred but requires that you keep both the access token and refresh token around in the eventuality that your access token expires.
The "expires" in the JSON indicates how long (in seconds) the access token is valid. You will also be given the "grant_time" which is when the access token was issued. You can use these two bits of information, if you wish to, to preemptively acquire a new access token ahead of it's expiration.
The management and juggling of tokens is a bit tedious. It's a large part, actually, of what our own drivers do (in Java, Node.js, etc).
That said, most HTTP Clients with OAuth 2.0 support will offer this functionality. And fortunately, given it's use among big players like Google, Microsoft, Twitter, Facebook, etc, the specification has a pretty active community around it.