HTTP tutorial - Authentication

As a rule, you will process business-relevant and very confidential data. Access to this must therefore be well secured, which can be achieved using various access control techniques (web authentication). We support the methods/schemes "Basic" and "Digest" for incoming data. In both cases, a user/password pair can be stored in an HTTP channel as well as in the profile itself. Details on this can be found in the online help.

For outgoing connections, in addition to the methods already mentioned above, OAuth in versions 1 and 2, NTLM and client certificates are also supported.

Basically, the workflow for authentication is as follows:


  • The client sends a request without credentials.

  • The server notices the missing credentials and sends back a status code (HTTP 401 - Unauthorised), as well as an HTTP header (WWW-Authenticate), in which the method to be used is specified (challenge).

  • The client reads the returned header (in which the authentication method is specified), e.g. WWW-Authenticate: Basic realm="RealmName" (authentication according to basic method).

  • The client uses the stored credentials to set them correctly, if possible.


Below is an overview of the methods and a detailed description can be found at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization.

Basic


In the basic procedure, the username and password are encoded in the form username:password according to the Base64 procedure and then set as HTTP headers in the following form:

Authorization: Basic d2lraTpwZWRpYQ==

It is important that Basic must be present in this form. The stored string means decoded wiki:pedia. Thus, this is username=wiki and password=pedia. To encode or decode Base64 strings, use the Create password tool in the Admin Console.

Important note: Basic transmits the credentials unencrypted in the header. Therefore, it should only be used in conjunction with HTTPS, otherwise an attacker can easily tap the access data.

Digest


Digest is more secure than Basic because the credentials are not transmitted directly. Instead, the client sends the checksum to the server as an MD5 hash from a combination of user name, password, nonce and realm. Since MD5 is no longer secure, the connection should also be made via HTTPS. There are other possibilities included in the standard to use newer digest methods, such as SHA256, but it must be assumed that not all clients implement these.

OAuth 2.0


With the methods Basic and Digest, credentials are always required in principle, which may have higher authorisations than required. The targeted granting or revoking of authorisations is not possible with these methods, which has some disadvantages:


  • If the user changes his password, for example, the configured access no longer works.

  • If one wants to deny access to a page (resource), this is not easily possible.

  • You cannot grant access for a limited period of time.

  • The access data can fall into the hands of an unauthorised person, with all the consequences that this entails.


Therefore, we recommend the approach of not using user credentials but rather a kind of time-limited 'user ID' (token) authorised for special purposes. The best-known and most widespread method is OAuth2, which is specified as a standard in RFC 6749.

Due to its high complexity, it is not further explained here. Have a look at https://oauth.net/.

NTLM


The entries for user name and password can be set via the Windows NT LAN Manager. The following syntax is then expected in the field for the user name (please note the double backslash):

NTLMv1 and v2 syntax

domain//user