Skip to main content

 

Documentation & User Guides | FotoWare

Web Application or API authorization

Web Application or API

This variant of the authorization process is for web applications or web APIs (from now on called web apps) containing code executed on the server side, such as PHP, ASP.NET, Python or Node.js. A web app is a confidential client, because it can securely store a secret on the server side without exposing it to users and user agents (browsers). Web apps use authorization code grant, which means that the client first receives an intermediate authorization code from the server, which is then used to request an access token for accessing the FotoWeb API. This two-step process requires the client to send a second request to the server, where the client authenticates itself using the client secret. This provides additional security and protection against malicious clients attempting to gain access tokens.

User Experience

  1. The user navigates to the client application in the browser
  2. If the user isn't already logged into FotoWeb in the browser, then the regular 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, which should display the name of the application, a 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 do actions on the user's behalf.

Application Registration

When registering the application in the FotoWeb site settings (Settings tab, then Services > Applications), choose Web App / API.
The configuration interface will generate 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 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

Parameter Description
client_id REQUIRED. The unique ID of the client, which was obtained during client registration.
code_challenge OPTIONAL: PKCE code challenge. See the block about PKCE below.
code_challenge_method OPTIONAL: PKCE code challenge method. See the block about PKCE below.
redirect_uri

The redirection endpoint URI of the client.

If given, it MUST match with one of the redirection endpoint URIs registered for the client.

OPTIONAL if the application only has one registration endpoint.

REQUIRED if the application has more than one registration endpoint.

response_type REQUIRED. Must always be code.
state

REQUIRED: This SHOULD be a unique, cryptographically safe random string.

Web applications are confidential clients which authenticate themselves using a client secret. The PKCE parameters, 
code_challengeand code_challenge_method, are therefore not required, but optional to provide a minimal amount of additional security. It is perfectly fine to not use PKCE for web applications, though.

For more information about PKCE, please see the section "Proof Key for Code Exchange" below.

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

On success, the server responds by redirecting the user to the redirection endpoint URI of the client. 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

 

Parameter Description
code The authorization code which is used to request the access token in the next request
state

This is always identical to the string passed to the request in the state parameter.

The client SHOULD check that the returned string is identical to the sent string.

This is to protect against cross-site request forgery (CSRF).

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 please 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

Parameter Description
grant_type REQUIRED. Must always be authorization_code.
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.

code REQUIRED. The authorization code which was returned by the authorization request.
redirect_uri

The redirection endpoint URI of the client.

REQUIRED if the redirection_uri parameter was also given in the authorization request, and its value must be identical.

MUST NOT BE GIVEN if the redirection_uri parameter was not given in the authorization request.

code_verifier OPTIONAL: PKCE code verifier. See the block about PKCE above.

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 refresh token that can be used to request a new access token. For more information, see the section "Refreshing Tokens".

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.

  • Was this article helpful?