Skip to main content
Documentation & User Guides | Fotoware

Non-interactive application authorization with OAuth 2.0

  1. Last updated
  2. Save as PDF

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

 

  1. From the Tools menu (cogwheel icon), go to Site Configuration > Integrations > Applications.
  2. Select Add application.
  3. From the Type drop-down list, select Non-interactive/script.
  4. Enter a name in the Name field. 
  5. Select Save. The configuration interface will generate a Client ID and a Client secret.

OAuth_for_non-interactive_app.png

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.