Welcome to the FotoWeb OAuth Demo Application

This application demonstrates how to build different kinds of applications that use the FotoWeb API and FotoWeb embeddable Widgets and OAuth 2.0 for user authorization.
This is the configuration page, where you choose the type of application and enter necessary details. In an actual application, these details would be either hard-coded or part of a fixed configuration that is hidden from its users.



A web application with a back-end (server) component.
  • BACK-END: The application must have a back-end (server) component for OAuth authorization, storing a client secret, and managing bearer tokens.
  • FRONT-END: The application may have a front-end (HTML and JavaScript), but it may also be an API only.
  • API: This application can make API requests to FotoWeb. An API license is required.
  • CONSENT: The authenticity of the application is verified, so it only has to ask for user consent upon first authorization.
  • SESSIONS: Refresh tokens can be used to keep the application permanently authorized.
A native (desktop or mobile) application.
  • API: This application can make API requests to FotoWeb. An API license is required.
  • CONSENT: The authenticity of the application cannot be verified, so it has to ask for user consent upon every authorization.
  • Refresh tokens can be used to keep the application permanently authorized.
A web application WITHOUT a back-end (server) component.
  • FRONT-END: The application consists of HTML and JavaScript only, so any data it stores is visible to the user and user agent (browser).
  • API: This application can make API requests to FotoWeb. An API license is required.
  • CONSENT: The authenticity of the application cannot be verified, so it has to ask for user consent upon every authorization.
  • SESSIONS: Users must authorize the application every time (no refresh tokens).
A web application which uses FotoWeb embeddable widgets only. This is the preferred approach for using widgets.
  • BACK-END: The application must have a back-end (server) component for OAuth authorization, storing a client secret, and managing bearer tokens.
  • API: This application CANNOT make API requests to FotoWeb. An API license is NOT required.
  • CONSENT: The authenticity of the application is verified, so it only has to ask for user consent upon first authorization.
  • SESSIONS: Refresh tokens can be used to keep the application permanently authorized.
A web application which uses FotoWeb embeddable widgets only.
  • FRONT-END: The application consists of HTML and JavaScript only, so any data it stores is visible to the user and user agent (browser).
  • API: This application CANNOT make API requests to FotoWeb. An API license is NOT required.
  • CONSENT: The authenticity of the application cannot be verified, so it has to ask for user consent upon every authorization.
  • SESSIONS: Users must authorize the application every time (no refresh tokens).
A legacy web application which uses FotoWeb embeddable widgets only and was written for an older version of FotoWeb.
  • No application registration is necessary.
  • CONSENT: The authenticity of the application cannot be verified, yet users are not asked for consent.
  • SESSIONS: Users must authorize the application every time (no refresh tokens).
The client ID of your application registered in your FotoWeb tenant (e.g., a838XXXX-XXXX-XXXX-XXXX-XXXXXXXX68df)
The client secret of your application registered in your FotoWeb tenant
You may enter a login token generated with the login token generator tool.
Remember to check the option "Use for widgets".
The encryption secret can be obtained from the tenant's site settings.