API Authentication & Connection Modes

BASIC Auth Authentication

Basic auth should be used only when testing services, and preferably in https because the credentials circulate in clear text (encoded in base64 in reality, but it is the same thing).

Concretely, the basic auth uses the Authorization header, with a value prefixed by Basic, followed by the credentials encoded in base 64.

Example:

Authorization: Basic bG9naW47cGFzc3dvcmQ=

Sessionless

In this mode, the surfer is connected to each call, which implies an execution of the surferservices at each call.

Sessionauth

In this mode, the current surfer (session or request), if it exists and if it is compliant, will be used, which will avoid a call of the surferservices at each call.

Sessionful

In this mode, we connect the surfer in session if there is not already one. So there is no connection at each call and therefore no execution of surferservices.

To work, you have to maintain the jsessionid between each call. Otherwise, we will work as in the sessionless mode, but with a session creation at each call, which can increase the load on the server.

JWT Token Authentication

This mode au authentification and authorization system is based on JSON Web Tokens open standard.

The system is based on three endpoints:

  • signin - one to connect and obtain 2 tokens in return, one for access, said to have a short lifetime, and one for refreshment, said to have a long lifetime.

  • token (or refresh)- another to get from a refresh token a new access token without having to reuse the user's credentials.

  • signout - a last one to destroy the tokens (revoke them)

Sessionless

Sessionful

JWT Token Authentication by bearer

The access token is used for authentication and authorization by being transmitted via the Authorization header, prefixed by the word Bearer.

Example

Authorization: Basic eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT Token Authentication by cookie

The REST API implements a mechanism to encapsulate tokens in cookies in order to simplify the connection in the context of a Web application running in a browser, especially for the html img tags which do not allow to use header Authorization. Of course, this system can be used in any system that implements a cookie maintenance system, such as the Unirest library, Insomnia or Postman…

The x-wedia-api-token cookie identifies the user connected to the session identified by the JSESSIONID cookie. Two other cookies are dedicated to the refresh or signin endpoints, respectively x-wedia-api-tk and x-wedia-api-so.

Sessionless mode and sessionauth option

Sessionful mode