User experience

1. The user navigates to the client application in the browser
2. If the user isn't logged into FotoWeb in the browser, then the standard FotoWeb login page is shown. Otherwise, proceed to step 3.
3. The user may be asked to authorize the application to access the user's information. This is done in a user interface that is part of FotoWeb. The interface displays the application's name, logo, and a list of permissions to be granted to the application.
4. The user is redirected to the application and signed in. The application can now use the FotoWeb API to access information in FotoWeb and carry out actions on the user's behalf.

Application registration

1. From the Tools menu (cogwheel icon), go to Site Configuration > Integrations > Applications. The Applications view opens. 
   
2. Select Add application (or Edit to edit an existing application).
3. Select a type from the Type drop-down list.

• If you select Native/mobile - enter a name in the Name field. In the Client ID field, you can enter an existing client ID or leave this field empty to generate a new client ID. Select Add to add redirect URIs.
• If you select Web App/ API - enter a name in the Name field and select Add to add redirect URIs.
• If you select Non-interactive/script - enter a name in the Name field.

4. Select Save. The client secret is displayed in the dialog that opens. 
   Note: Make a note of the client secret (or store it immediately in the application code or configuration), as there is no way to recover it after application registration. If the client secret is lost, you must generate a new one in the application registration interface.
5. Select OK to close the dialog. The newly registered application is now listed in the Applications view. 

User consent

A custom text can be added to the user consent dialog in Markdown format. It is also possible to include a URI on a privacy policy web page that governs the use of the system.

This information will be displayed in the consent dialog when the application requests access to the site so the user can review it before proceeding.

Protocol flow

The client opens a browser window to the following URL (line breaks are added for readability. All parameter values must be URL-encoded):

https://myfotowebserver.com/fotoweb/oauth2/authorize?
 response_type=code&
 client_id=CLIENT_ID&
 redirect_uri=REDIRECT_URI&
 state=STATE&
 code_challenge=CODE_CHALLENGE&
 code_challenge_method=S256

 where

OAuth clients are REQUIRED to use the PKCE parameters code_challenge and code_challenge_method for additional security. However, for legacy reasons, these parameters are OPTIONAL for web applications.We strongly recommend using PKCE, as recommended by the OAuth standard.
For more information on generating the value for code_challenge, see the Proof Key for Code Exchange.

This request may result in the user being shown a login prompt for FotoWeb.

Upon success, the server responds by redirecting the user to the client's redirection endpoint URI. This is always one of the redirection endpoint URIs registered for the client and if given, the redirection URI passed in the request as redirect_uri.

Parameters are added to the query part of the redirection URI as follows (line breaks added for readability). All parameter values are URL-encoded:

https://myapplication.com/oauth2/callback?
 code=AUTHORIZATION_CODE&
 state=STATE

where

The client then makes the following request to the token endpoint to obtain the access token (line breaks are added for readability).

This request MUST NOT be sent by the user agent (browser), as it would expose client credentials and access tokens to the user agent, resource owner and potentially others. For example, if the client is a web application, then this request SHOULD be sent by the back-end (server) of the application, rather than JavaScript code running in the browser (which would also fail due to cross-site request limitations (CORS)).

If the client is a web application without a back-end (pure AJAX application with a static web server), or sending the request from the back-end is not feasible, then you can use the authorization process for single-page JavaScript web apps without back-end instead.

All parameter values MUST be URL-encoded.

POST https://myfotowebserver.com/fotoweb/oauth2/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=authorization_code&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&code_verifier=CODE_VERIFIER

where

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

The application can obtain the access token by parsing the response body.

Refresh tokens are highly sensitive, as they have long (or infinite) expiration times and can be used to request new access tokens.

A client SHOULD store the refresh token in a safe place so it cannot be accessed by unauthorized parties. A client SHOULD NOT expose a refresh token to a user agent (browser). A client that does not use refresh tokens SHOULD NOT store the refresh token at all.