Table of Contents
Refreshing tokens
Table of Contents
For security and performance reasons, access tokens have a limited, usually very short lifetime. After an access token expires, the client must request a new one to continue using the FotoWeb API. There are 2 ways to do so:
- Repeat the authorization process
- Request a new access token using a refresh token
Refresh tokens may be obtained together with access tokens if the authorization code grant type is used. Refresh tokens are not available when using the implicit grant type.
A new access token is requested using a refresh token as follows:
POST https://myfotowebserver.com/fotoweb/oauth2/token Content-Type: application/x-www-form-urlencoded Accept: application/json grant_type=refresh_token&refresh_token=REFRESH_TOKEN&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
where
| Parameter | Description |
|---|---|
grant_type |
REQUIRED. Must always be refresh_token. |
client_id |
REQUIRED. The unique ID of the client, which was obtained during client registration. |
client_secret |
The client secret, obtained during client registration. REQUIRED if the client is a web application (was registered with a client secret). MUST NOT BE GIVEN if the client is a native application or single-page application (was registered without a client secret). |
refresh_token |
REQUIRED. The refresh token obtained during authorization. |
On success, the server responds as follows:
200 OK Content-Type: application/json
with the following response body:
{
"access_token": ACCESS_TOKEN,
"token_type": "bearer",
"expires_in": EXPIRES_IN_SECONDS,
"refresh_token": REFRESH_TOKEN
}
where
| Parameter | Description |
|---|---|
access_token |
The access token that is used to authorize requests to the FotoWeb API |
token_type |
This is always bearer. |
expires_in |
Number of seconds after which the token is expected to expire. |
refresh_token |
OPTIONAL: A new refresh token. |
The application can obtain the access token by parsing the response body.
If FotoWeb issues a new refresh token in the response, then the old refresh token (i.e. the refresh token used in the request) is no longer valid.
It is unspecified if and when FotoWeb will issue new refresh tokens when they are used to request new access tokens, so the client MUST support this case, even if it appears that FotoWeb does not issue new refresh tokens.
Refresh token life span
Refresh tokens have an unlimited lifetime. However, future versions may be able to limit the refresh token lifetime. Also, both users and administrators may perform actions that cause refresh tokens to be deleted (e.g., changing application settings or logging out of all sessions).
Applications need to handle the case where a refresh token has been invalidated and, in this case, should either ask the user to re-authenticate or show an error message (depending on what is best suited to the situation).
For this reason, it is not recommended to use refresh tokens for non-interactive applications, as the user would not be able to take action when a refresh token is invalidated. For non-interactive applications, see Non-interactive application authorization with OAuth 2.0
Note
An application that uses refresh tokens should provide a Log out button, or another easily accessible option, for users to delete the refresh token and re-authenticate (for example, by using a different user account and granting different permissions). If an application only stores the refresh token in the memory and not on disk, then restarting the application may be an acceptable method to log out.
Users may not be familiar with terms such as refresh tokens or authenticate, so Log out or Sign out are more user-friendly labels for a button, even if they are technically incorrect in OAuth terminology.