The Token Authentication allows users to gain system access using Access Tokens. The tokens can be created by the user in their User Data menu. Each token can be assigned one or more access permissions.

Access Tokens are an alternative means of authentication, allowing access to URL path extensions of the i-net Clear Reports server. An Access Token, once generated, will not be presented again to the user, so they have to be copied and securely stored. It is possible to regenerate a token - without loosing the permissions - in case of a compromised or lost token.

URL path extensions are defined by additional plugins, such as the Web API. Users with the Token Authentication permission can select multiple path extensions that can be accessed using a given Access Token.

There are two types of Access Tokens that are supported:

• Bearer Token
• HMAC Token

Note: Access Token do not extend the privileges a user was given due to their permissions in the system. URL path extension access restrictions of an Access Token as well as the users permissions apply at the same time. This means you must explicitly grant access under 'Application Permissions' for all components/paths you want to access via the Access Token.

A Bearer Token is being used for stateless requests to the i-net Clear Reports server, e.g. via the Web API. The Token Key is generated automatically when creating a new Bearer Token entry. It is presented to the Server using the Authorization header using the following form:

# Request
GET /api/jobmanager HTTP/1.1
Authorization: Bearer 90fs7vt7ujdqubbbn01q34n9g65t4742gezdcwuyhcbcryqqye

Note: The Access Token is composed of a public and a private component. The public part, being the first 25 characters, can be used to search for the users account in the Users and Groups manager.

The HMAC Token authentication is based up on a hashed key that is created using the secret and the content of the request. That means, that the secret key is never directly transmitted from the client to the server, but both sides have to have knowledge of the key.

Usually the service side (aka client) provides the key which has to be set up in the configuration of the user.

A client side Java code may look like:

    // Note, this code is incomplete!
    // The HMAC Token "f1h3g4zt598d7t47hg3723j22b" is only exemplary.
    // This is specified Base64 encoded in the interface and must therefore be decoded first.
    byte[] secretKey = Base64.getDecoder().decode( "f1h3g4zt598d7t47hg3723j22b" );
    String hmac = Base64.getEncoder().encodeToString( calcHmacSha256( secretKey, content ) );
    conn.setRequestProperty( "Authorization", "HMAC " + hmac );
    conn.setDoOutput( true );
    conn.setRequestProperty("content-type", "text/plain; charset=utf-8");
    conn.getOutputStream().write(  content );
    InputStream in = conn.getInputStream();
 
    static public byte[] calcHmacSha256(byte[] secretKey, byte[] message) {
        try {
            Mac mac = Mac.getInstance( "HmacSHA256");
            SecretKeySpec secretKeySpec = new SecretKeySpec( secretKey, "HmacSHA256");
            mac.init(secretKeySpec);
            return mac.doFinal(message);
        } catch (Exception e) {
            throw new RuntimeException("Failed to calculate hmac-sha256", e);
        }
    }