Table of Contents
Non-interactive application authorization with OAuth 2.0
01. April 2025
Table of Contents
Non-interactive applications
This variant of the authorization process is for non-interactive applications, i.e., apps in which there is no user interaction. A non-interactive application gets full administrative access to all resources on the tenant; it is impossible to make requests in the context of a user.
Note: Refresh tokens are no longer supported for non-interactive integrations. There is no benefit for a non-interactive integration to use refresh tokens, as it might as well use client credentials to request a new access token. this change has been made for simplicity and to improve security. Refresh tokens can become invalid at any time, so an integration that uses them must always handle the case that a refresh token is rejected (typically by repeating authorization). Therefore, any legacy non-interactive integrations that rely on refresh tokens should still work as designed as long as they are implemented correctly. If your non-interactive integration uses refresh tokens, you can remove all support for refresh tokens and always use client credentials for requesting a new access token. Refresh tokens are supported for interactive applications and will continue to be so. No changes have been made to how they work, and their use is still encouraged when they are beneficial (to let a user stay 'logged in' to an interactive application.
Note: OAuth for non-interactive applications is intended for use with server applications or scripts, not for public clients or browser apps. The client secret must not be exposed to users or other unauthorized persons.
Registering an application
- From the Tools menu (cogwheel icon), go to Site Configuration > Integrations > Applications.
- Select Add application.
- From the Type drop-down list, select Non-interactive/script.
- Enter a name in the Name field.
- Select Save. The configuration interface will generate a Client ID and a Client secret.
Make a note of the client secret (or store it immediately in application code or configuration), as there is no way to recover it after application registration. If the client secret is lost, then you have to generate a new one in the application registration interface.
Protocol flow
The client makes the following request to the token endpoint to obtain the access token. Line breaks are added for readability.
All parameter values MUST be URL-encoded.
POST https://myfotowebserver.com/fotoweb/oauth2/token Content-Type: application/x-www-form-urlencoded Accept: application/json
and with these parameters in the body
grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
where
| Parameter | Description |
|---|---|
grant_type |
REQUIRED. Must always be client_credentials
|
client_id |
REQUIRED. The unique ID of the client, which was obtained during client registration. |
client_secret |
REQUIRED. The secret of the client, which was obtained during client registration. |
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,
}
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. |
What's next?
Learn how to use OAuth access tokens in your integration.