Web Services Authentication Mechanisms

Part of the security of web services are authentication and authorization mechanisms, allowing access to the data only for the corresponding persons. The question is how well known are the restrictions. These settings should include appropriate architecture, protection and detection means. Today, web portals are used in all organizations, and inappropriate data protection has consequences.

Web Browser Authentication Mechanisms

Another loose continuation of authentication mechanisms deals with the issue of web browsers this time. Their access to authentication data protection is very loose and relies mainly on transport encryption. Unfortunately, the SSL/TLS layer has its limitations, which must be taken into account. Therefore, it is necessary to start explaining how the HTTP authentication itself works, what the SSL/TLS layer offers, and where these methods meet.
The most often underestimated impact on the security of authentication mechanisms is the passing of parameters within the URL, when the passed values are stored, for example, in traffic records. Another vice is the underestimation of the necessary security, part of the pages may have protection set, but in case of redirection to the authentication portal, this protection is missing. Similarly, SSL/TLS security is problematic, when the protection against a possible SSL Inspection is not set. As a last influence, it is also necessary to include the telemetry information of the browser, the ability to automatically correct text or various plugin modules, which send information to their authors. Therefore, browsers cannot be taken as safe environment and authentication algorithms should always require an additional factor for the reasons given.

HTTP protocol authentication principles

In case of accessing a web address, the normal response to a GET query from a web page is OK 200. Subsequently the requested data is sent. In case of accessing protected content, however, the communication is slightly different. In case of a GET query, the page returns the code 401 Unauthorized, which forces authentication by the client. If the authentication ends in an error, the code 403 Forbidden is returned. Of course, other codes are possible, such as the code 404 Not Found, but this is no longer related to authentication.

Authentication mechanisms available

Currently, the most commonly used mechanisms in the table below are available for both Brave browsers, Chrome, Chromium, Edge, Firefox, Opera, Safari, Vivaldi and more. On the web site side, such as Apache, Apache Tomcat LightHttp, Microsoft IIS and NGINX are the same set. The difference here is created by support for internal infrastructure, where additional mechanisms such as Kerberos, LDAP and SAML are supported.

HTTP Basic Authentication

This is the simplest form of authentication. In case of detection of authentication request, i.e. return of error message 401 Unauthorized along with WWW-Authenticate: Basic realm="Secure Area" will be headed on next HTTP query added value to request:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK
The text string behind the authentication type definition contains the string username:password encoded using Base64. Because it is an encryption, not an encryption, it is necessary to use transport encryption protection (SSL/TLS). In another In case it is possible to obtain the original username and password extremely easily.

Channel Binding: No
Realms: No
Cryptoprimitives: No
Authentication participants: 2
PQC/QRC: No
ZKP: No
Crypt interface support: Server side
Tokenization: No
Uniqueness: No
Credentials protection: No
Replay protection: No
Protection against Relay: No
Hijack protection: No
Forge protection: No
MFA support: Possible, there must be application level support
Integrity protection: No
Encryption type: No, necessary to use SSL/TLS

HTTP Digest Authentication

This is a slightly improved but still outdated form of authentication. Unlike plaintext authentication, hash usage occurs MD5. The weaknesses of the hash function led to the release of the new RFC 7616 in 2015, which allowed the MD5 function to be replaced by hash functions of the SHA2 family (SHA2-256, SHA2-384, SHA2-512, SHA2-512/256). When using HTTP Digest Authentication with hash function SHA2 thus significantly improves its safety properties. Custom login again occurs in case of access to deny access using the error message 401 Unauthorized along with the following information:
WWW-Authenticate: Digest
realm="Secure Area", nonce="000102030405060708090a0b0c0d0e0fff",
qop="auth", opaque="5ccc069c403ebaf9f0171e9517f40e41"

Based on the answer, it is possible to detect whether the standard MD5 algorithm is used or a new standard with SHA2 support. In the case of in the SHA2 hash function, the response is extended by algorithm=SHA-256. Client detecting authentication request subsequently asks to be connected again. In the header this time it will add some data from refusal of access along with information that can server perform its authentication. These are the following dates:
Authorization: Digest username="user", realm="Secure Area",
nonce="000102030405060708090a0b0c0d0e0fff", uri="/secure",
response="123456789abcdef123456789abcdefff", qop=auth, nc=00000001, cnonce="02468ace"

The answer is calculated as the result of the hash function (example for MD5) with the following content.
response = MD5(MD5(username:realm:password)+nonce+nc+cnonce+qop+MD5(method:uri)

Channel Binding: No
Realms: No
Cryptoprimitives: MD5, SHA2
Authentication participants: 2
PQC/QRC: No
ZKP: No
Crypt interface support: Server side
Tokenization: No
Uniqueness: No
Credentials protection: Yes
Replay protection: Yes
Relay protection: No
Hijack protection: No
Forge protection: Yes
MFA support: Possible, there must be application level support
Integrity protection: No
Encryption type: Hash, necessary to use SSL/TLS

TLS Client Certificate Authentication

In the case of authentication using a client certificate, the most common problem is a possible misstep with mTLS (mutual TLS), because these are extremely similar technologies. In normal TLS connection-making, a server certificate is provided in order to initialize a secure connection. Even in this area, there is a simple misstep, as it does not verify the server's correct certificate, but it does verify its validity and some of the certificate's properties. These are two different pieces of information with different meanings.

In the case of detection of an authentication request, an error message 401 Unauthorized is returned along with the information:
WWW-Authenticate: TLS-Cert Other alternatives requiring certain conditions are answers containing outside of the certificate request further clarifications of their various combinations:
• Certificate's affiliation to a specific CA
  nbsp;WWW-Authenticate: TLS-Cert, CA="CN=TrustedAuthority, O=Organization, C=Country"
• Required attribute
 WWW-Authenticate: TLS-Cert, Subject="CN=Name Surname, O=Organization"
• Required specific policy
 &&&& WWW-Authenticate: TLS-Cert, Policy="1.2.840.113549.1.1.11"
• Required specific certificate signing algorithm
 & WWW-Authenticate: TLS-Cert, Alg="ECDSA"
Other parameters include SAN (Subject Alternate Name), Serial Number, and certificate imprint. Based on the information obtained the client terminates the connection and creates a new one where it provides the server with information about its client certificate.
During the process of establishing the prompt that the client signs is exchanged. The client of the server, based on its request (Certificate Request), additionally responds with the requested information about its certificate.
Client Certificate: [Base64-encoded X.509 certificate] Signature: [Digitally signed challenge]
This is actually a classic Client Certificate message during the TLS connection initialization. Subsequently, the server checks whether the client certificate is valid and meets the defined conditions. Then, the client reapplies for access to the source, the server, based on the available information, pairs the client certificate against the source authentication requirements. This is therefore an optional authentication of the client, usually used for VPNs and secure sites. For establishing the connection to the communication channel (Channel Binding), it can be used tls-unique and tls-server-end-point, where tls-unique in TLS 1.3 is no longer supported.
In the case of mTLS, during the TLS layer-level connection, the server certificate is provided in order to initialize the secure connection. Even during this initialization, the server requires a certificate, but here it is a mandatory authentication of the client. It is usually used for various APIs, micro-service communications or even Kubernetes.
An interesting feature of TLS Client Certificate Authentication is the possibility of user authentication and specific links to a certificate, for example using a user database, Active Directory or LDAP database, OAuth 2.0 and OpenID Connect. In this case, it is possible to proceed with further comparison of certificate properties on the application layer.

Channel Binding: Possible
Realms: No
Crypto-primitives: by ciphersuites SSL/TLS
Attendees authentication: 2
PQC/QRC: Not by default, possible by TLS 1.3
ZKP: No
Support crypt: No
Tokenization: No
Uniqueness: Yes
Protection credentials: Yes
Protection against Replay: Yes
Protection against Relay: Yes
Protection against Hijack: Yes
Protection against Forge: Yes
Support for MFA: Possible, there must be support at the application level
Integrity protection: Yes
Encryption type: SSL/TLS, part of authentication

WebAuthn

Currently, the most widely publicized authentication standard is WebAuthn, which allows you to use a variety of methods to authenticate key material or support biometric authentication. The goal is to minimize the use of passwords, which are often characterized by low entropy, lack of randomness and unpredictability, in favor of key material. Key material is unique to the user/server combination. This also reduces the risk of multiple use of identical passwords across different systems. On the server side, there is no need for a password database, which reduces the likelihood of their leakage. Public keys are useless to the attacker, as a matter of principle they are available to everyone. Furthermore, this protocol requires the use of at least TLS 1.2 or higher version to protect the transferred information.
WebAuthn works very simply by using asymmetric cryptography. At the beginning, the client generates a pair of keys. The private key remains locally stored (TPM, token, enclave, strongbox). The public key is then registered on the server side. As a result, the server has information about the user and the corresponding public key. In case of use of biometric verification biometrics are only used to allow access to key material. If the user wants to log in, sends information about the server request. The client then sends a call, which the client signs and sends back to the server. There is thanks signature verification options using a public key can get information if the corresponding user is logging in.

Registration:
Server → Client:  C_S = RND (32B)
Client:        M = C_S || CredentialID || K_Public
Client:        Signature = DSA (K_Private, M)
Client → Server:  Response={M, Signature}

Login:
Server → Client:  C_S=RND(32B)
Client:        M=C_S∥ClientData∥AuthenticatorData
Client:        Signature=DSA(K_Private,M)
Client → Server:  Response={C_S,AuthenticatorData,Signature,credentialId}

Channel Binding: Possible
Realms: No
Cryptoprimitives: by ciphersuites SSL/TLS
Authentication participants: 2
PQC/QRC: Not by default, possible with TLS 1.3
ZKP: No
Crypt interface support: No
Tokenization: No
Uniqueness: Yes
Credentials protection: Yes
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: Yes
Protection against Forge: Yes
MFA support: Possible, there must be application level support
Integrity protection: Yes
Encryption type: SSL/TLS, authentication included

OAuth 2.0

Outside the upcoming WebAuth, which is especially popular because of its connection with various tokens (Yubikey, Titan …) or TPM, are another popular method of authentication third-party systems. These provide authentication and provide authorization information for accessing web portals or applications. In case of OAuth 2.0 it is possible to use the functionality of federated verification. This algorithm is described among the SASL mechanisms in another article, so here I will describe only the basic difference when using the web interface. If necessary, understand the principle of operation I recommend using the link dedicated to this protocol The OAuth 2.0 interface requires the use of TLS 1.2+ to ensure secure communication. Unlike OpenID Connect allows the use of a refresh token to create a new token request. The procedure then looks approximately as follows. Client tries to sign in with a specific token or accesses without a token: Authorization: Bearer <expired_token>

The server returns an error message that indicates an invalid or expired token. The same way returns it even if when the user has not yet been logged in.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="REALM", error="invalid_token", error_description="The access token is expired"

The client needs to get the corresponding token, so they need to log in again on the authentication server:

Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=<refresh_token>&client_id=<client_id>&client_secret=<client_secret>

Authentication server issues a new token:
HTTP/1.1 200 OK
Content-Type: application/json

{
  nbsp nbsp;"access_token": "new_access_token",
  nbsp nbsp;"token_type": "Bearer",
  nbsp nbsp;"expires_in": 3600
}

The client connects to the application server again:
Authorization: Bearer new_access_token

And if the token is correct, the application server will allow access:
HTTP/1.1 200 OK

Channel Binding: No
Realms: Yes
Crypto-primitives: Obsolete (RSA), current (SHA256, ECDSA)
Pages on authentication: 3 to 4
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Relay protection: Yes
Hijack protection: Yes
Forge protection: Yes
MFA support: Yes
Integrity protection: TLS, internal for JWT
Encryption type: TLS, internal for JWT

OpenID Connect

OpenID Connect is a variant of OAuth 2.0 and is also described in a separate article. Here, too, the basic differences are described using the web interface. If necessary to understand the principle of operation I recommend to use the link dedicated to this protocol OpenID Connect requires the use of TLS 1.2+ to ensure secure communication. Unlike OAuth 2.0, it requires a new login to create a request for a new token. The verification procedure then looks like the following:
Client tries unsuccessfully to log in, server requests authorization
Authorization: Bearer

The server responds to the OIDC authentication request
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example", error="invalid_token", error_description="ID Token expired"

The client is redirected to the authorization server, if it does not have a refresh token, it must be logged in again

GET https://auth.example.com/authorize?client_id=client&response_type=code
&scope=openid profile email&redirect_uri=https://client.example.com/callback
&state=random_state

Authorization server provides authorization code:
HTTP/1.1 302 Found
Location: https://client.target.tld/callback?code=code&state=random_state

The client asks for ID and access token after login
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=code&redirect_uri=https://client.example.com/callback
&client_id=client&client_secret=client_secret

After authentication, the authorization server returns the ID and access token:
HTTP/1.1 200 OK
Content-Type: application/json

{
   nbsp;"access_token": "new_access_token",
   nbsp;"id_token": "new_id_token",
   expires_in": 3600"
}

The client logs in again with the relevant information
Authorization: Bearer new_access_token
And if the token is correct, access is allowed
HTTP/1.1 200 OK

Channel Binding: No
Realms: Yes
Cryptoprimitives: Obsolete (RSA), current (SHA256, ECDSA)
Number of pages when authenticating: 3 to 4
PQC/QRC: No
ZKP: No
Crypt interface support: Under certain conditions
Tokenization: Yes
Uniqueness: Yes
Credentials protection: TLS
Replay protection: Yes
Protection against Relay: Yes
Hijack protection: Yes
Protection against Forge: Yes
MFA support: Yes
Integrity protection: TLS, for JWT internal
Encryption type: TLS, internal for JWT

Conclusion

Using the integrated mechanisms of browsers is a simple method, but it requires an understanding of the function of the protective mechanisms. Without knowledge of the facts, it is not possible to set security responsibly, which can have fatal consequences for data security. mechanisms are a basic defensive barrier, their configuration is necessary, but not sufficient. The same care is required to also allocate permissions and other layers of protection.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.