Skip to main content
Documentation & User Guides | Fotoware

Authorization using implicit grant (deprecated)

How to authorize applications using implicit grant.

Note: Implicit grant is deprecated in OAuth 2.1

For information about how to register the application, see application registration

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):




response_type Mandatory. Must always be token.
client_id Mandatory. The unique ID of the client, which was obtained during client registration.

The redirection endpoint URI of the client.

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

Optional if the application only has one registration endpoint.

Mandatory if the application has more than one registration endpoint.


Mandatory: This should be a unique, cryptographically safe random string.

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 endpoints registered for the client and if given, the redirection URI passed in the request as redirect_uri.

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




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.

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 application can obtain the access token by parsing the fragment part of the redirection URL.

The server will not issue a refresh token if implicit grant is used. When the access token has expired, the only way to obtain a new access token is to repeat authorization.

Implementation in JavaScript

The following JavaScript functions can be used to implement OAuth 2.0 in a single-page application:

function createState()
    var text = "";
    var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_~.";
    for (var i = 0; i < 16; ++i)
        text += possible.charAt(Math.floor(Math.random() * possible.length));

    return text;

function requestAuthorization(tenantURL, clientID, redirectURI)
    var state = createState();
    sessionStorage.setItem('state', state);

    window.location = tenantURL + "/fotoweb/oauth2/authorize?" +
        "response_type=token&" +
        "client_id=" + clientID + "&" +
        "redirect_uri=" + encodeURIComponent(redirectURI) + "&" +
        "state=" + encodeURIComponent(state);

function getAccessToken()
    var state = sessionStorage.getItem('state');
    if (state === null) return null;

    var params = window.location.hash.substring(1).split('&');
    var token = null;
    var stateValid = false;
    for (var i = 0; i < params.length; ++i)
        var pair = params[i].split('=');
        if (decodeURIComponent(pair[0]) === 'access_token')
            token = decodeURIComponent(pair[1]);
        else if (decodeURIComponent(pair[0]) === 'state') {
            if (state === decodeURIComponent(pair[1]))
                stateValid = true;
                alert("Invalid state! Someone is trying to mess with you!")

    if (stateValid)
        return token;

    return null;

The requestAuthorization function redirects the user to the authorization endpoint of FotoWeb. It may be called, for example, when the user selects a Log in with FotoWeb button. The parameters are as follows:

The getAccessToken function reads the access token from the fragment part of the URL after authorization is successful.

This implementation validates the OAuth 2.0 state parameter by creating a random value before the authorization process and passing it to the getAccessToken function using session storage.

This prevents cross-site request forgery (CSRF) and embedding the app into other apps (mash-ups) by ensuring that the app only accepts access tokens it has itself requested.

Any additional parameters to the application may be passed through the authorization process in session storage.

What's next? 

To learn how to use OAuth access tokens in your configuration, see Using application access tokens for OAuth 2.0 authorization.

  • Was this article helpful?