Geekly Articles each Day
📜 ⬆️ ⬇️

Overview of authentication methods and protocols in web applications



I will talk about the use of various authentication methods for web applications, including password authentication, certificate authentication, one-time password authentication, access keys and tokens. I will address single sign-on technology (Single Sign-On), consider various standards and authentication protocols.

Before moving on to the technical details, let's refresh the terminology a little.
')


For example, when you try to get to a private club, you are identified (asked for your first and last name), authenticated (asked to show your passport and checked on a photo) and authorized (check that the last name is in the guest list) before being allowed inside.

Similarly, these terms are used in computer systems, where traditionally, identification means getting your account (identity) by username or email; under authentication — verification that you know the password for this account, and under authorization — verification of your role in the system and the decision to grant access to the requested page or resource.

However, in modern systems there are more complex authentication and authorization schemes, which I will discuss below. But let's start with a simple and understandable.

Password authentication

This method is based on the fact that the user must provide username and password for successful identification and authentication in the system. The username / password pair is set by the user upon his registration in the system, while the username may be the user's email address.

For web applications, there are several standard password authentication protocols that we will discuss below.

HTTP authentication

This protocol, described in HTTP 1.0 / 1.1 standards, has existed for a long time and is still actively used in corporate environments. Applies to websites works as follows:

  1. The server, when an unauthorized client accesses a protected resource, sends the HTTP status “401 Unauthorized” and adds the “WWW-Authenticate” header indicating the scheme and authentication parameters.
  2. The browser, upon receipt of such a response, automatically displays the input dialog username and password. The user enters his account details.
  3. In all subsequent requests to this website, the browser automatically adds the HTTP header “Authorization”, in which the user data is transmitted for authentication by the server.
  4. The server authenticates the user based on this header. The decision to grant access (authorization) is made separately on the basis of the user's role, ACL or other account data.


The whole process is standardized and well supported by all browsers and web servers. There are several authentication schemes that differ in security level:

  1. Basic is the simplest scheme in which the username and password of a user are transmitted in the Authorization header in an unencrypted form (base64-encoded). However, using the HTTPS (HTTP over SSL) protocol is relatively secure.

    An example of HTTP authentication using the Basic scheme.

  2. Digest is a challenge-response scheme in which the server sends a unique nonce value, and the browser transmits the MD5 hash of the user's password, calculated using the specified nonce. A safer alternative to the Basic scheme for unprotected connections, but is subject to man-in-the-middle attacks (with the replacement of the scheme on the basic). In addition, the use of this scheme does not allow using modern hash functions for storing user passwords on the server.
  3. NTLM (known as Windows authentication) is also based on a challenge-response approach, in which the password is not transmitted in its pure form. This scheme is not an HTTP standard, but is supported by most browsers and web servers. It is mainly used to authenticate Windows Active Directory users in web applications. Vulnerable to pass-the-hash attacks.
  4. Negotiate is another Windows authentication scheme that allows the client to choose between NTLM and Kerberos authentication. Kerberos is a more secure protocol based on the principle of Single Sign-On. However, it can function only if the client and the server are in the intranet zone and are part of the Windows domain.

It is worth noting that when using HTTP authentication, the user does not have the standard opportunity to exit the web application, except to close all browser windows.

Forms authentication

There is no specific standard for this protocol, so all its implementations are specific for specific systems, and more specifically, for authentication modules of development frameworks.

It works according to the following principle: an HTML form is included in the web application, in which the user must enter his username / password and send them to the server via HTTP POST for authentication. If successful, the web application creates a session token, which is usually placed in browser cookies. In subsequent web requests, the session token is automatically transmitted to the server and allows the application to obtain information about the current user to authorize the request.


Example forms authentication.

An application can create a session token in two ways:

  1. As an identifier for an authenticated user session stored in server memory or in a database. The session should contain all the necessary information about the user to authorize his requests.
  2. As an encrypted and / or signed object containing data about the user, as well as a validity period. This approach allows the stateless architecture of the server to be implemented, however, it requires a mechanism for updating the session token after the expiration date. Several standard formats for such tokens are discussed in the “Token authentication” section.

It should be understood that intercepting session token often provides a similar level of access as knowledge of username / password. Therefore, all communications between the client and the server in the case of forms authentication should be made only over a secure HTTPS connection.

Other password authentication protocols

The two protocols described above are successfully used to authenticate users on websites. But when developing client-server applications using web services (for example, iOS or Android), along with HTTP authentication, non-standard protocols are often used in which data for authentication is transmitted in other parts of the request.

There are only a few places where you can pass username and password in HTTP requests:

  1. URL query - is considered an insecure option, since URL strings can be remembered by browsers, proxies, and web servers.
  2. Request body is a safe option, but it is applicable only to requests containing the message body (such as POST, PUT, PATCH).
  3. HTTP header is the optimal variant, while the standard Authorization header can be used (for example, with the Basic schema), and other arbitrary headers.


Common vulnerabilities and implementation errors

Password authentication is considered not a very reliable way, since passwords can often be picked up, and users tend to use simple and identical passwords in different systems, or write them on pieces of paper. If the attacker was able to figure out the password, the user often does not know about it. In addition, application developers can make a number of conceptual errors that simplify hacking accounts.

Below is a list of the most common vulnerabilities when password authentication is used:



Certificate Authentication

A certificate is a set of attributes that identify the owner, signed by certificate authority (CA). CA acts as an intermediary who guarantees the authenticity of certificates (by analogy with the FMS, which issues passports). Also, the certificate is cryptographically linked to the private key, which is stored with the certificate holder and allows you to unequivocally confirm the fact of ownership of the certificate.

On the client side, the certificate along with the private key can be stored in the operating system, in the browser, in a file, on a separate physical device (smart card, USB token). Usually, the private key is additionally protected with a password or PIN code.

Web applications traditionally use X.509 standard certificates. Authentication using an X.509 certificate occurs at the time of connecting to the server and is part of the SSL / TLS protocol. This mechanism is also well supported by browsers that allow the user to select and apply a certificate if the website allows this authentication method.


Using a certificate for authentication.

During authentication, the server verifies the certificate based on the following rules:

  1. The certificate must be signed by a trusted certification authority.
  2. The certificate must be valid for the current date (validity check).
  3. The certificate should not be revoked by the corresponding CA (checking exclusion lists).



Certificate Example X.509.

After successful authentication, the web application can authorize the request based on certificate data such as subject (owner name), issuer (issuer), serial number (certificate serial number) or thumbprint (certificate public key fingerprint).

Using certificates for authentication is a much more reliable way than password authentication. This is achieved by creating a digital signature during the authentication process, the presence of which proves the fact of the use of the private key in a particular situation (non-repudiation). However, difficulties with the distribution and support of certificates makes this authentication method inaccessible in wide circles.

One-time password authentication

One-time password authentication is usually applied in addition to password authentication for two-factor authentication (2FA). In this concept, the user needs to provide two types of data to log in: something that he knows (for example, a password), and something that he owns (for example, a device for generating one-time passwords). The presence of two factors allows to significantly increase the level of security that m. B. claimed for certain types of web applications.

Another popular scenario for using one-time passwords is additional user authentication when performing important actions: transferring money, changing settings, etc.

There are various sources for creating one-time passwords. Most Popular:

  1. Hardware or software tokens that can generate one-time passwords based on the secret key entered into them and the current time. User secret keys, which are a factor of ownership, are also stored on the server, which allows you to verify the entered one-time passwords. An example of hardware implementations of tokens - RSA SecurID ; software - Google Authenticator application.
  2. Randomly generated codes transmitted to the user via SMS or other communication channel. In this situation, the ownership factor is the user's phone (more precisely, the SIM card tied to a specific number).
  3. Listing or scratch card with a list of pre-formed one-time passwords. For each new login you need to enter a new one-time password with the specified number.



The RSA SecurID hardware token generates a new code every 30 seconds.

In web applications, this authentication mechanism is often implemented through the expansion of forms authentication: after the initial password authentication, a user session is created, but in the context of this session the user does not have access to the application until he performs additional authentication using a one-time password.

Access Key Authentication

This method is most often used to authenticate devices, services, or other applications when accessing web services. Here, as a secret, access keys ( access key, API key ) are used - long unique strings containing an arbitrary set of characters, in effect replacing the username / password combination.

In most cases, the server generates access keys upon request from users, which further store these keys in client applications. When creating a key, it is also possible to limit the period of validity and the level of access that the client application will receive when authenticating with this key.

A good example of using key authentication is the Amazon Web Services cloud. Suppose a user has a web application that allows you to upload and view photos, and he wants to use Amazon S3 to store files. In this case, the user can create a key through the AWS console that has limited access to the cloud: read / write its files only in Amazon S3. As a result, this key can be used to authenticate a web application in the AWS cloud.


An example of the use of authentication by key.

Using keys allows you to avoid transferring the user's password to third-party applications (in the example above, the user saved the access key in the web application, not his password). Keys have much more entropy than passwords, so it’s almost impossible to pick them up. In addition, if the key was disclosed, it does not compromise the main user account - you just need to cancel this key and create a new one.

From a technical point of view, there is no single protocol: the keys can be transmitted in different parts of the HTTP request: URL query, request body or HTTP header. As with password authentication, the best option is to use the HTTP header. In some cases, use the Bearer HTTP scheme to transfer a token in the header (Authorization: Bearer [token]). To avoid interception of keys, the connection to the server must be secured with SSL / TLS.


An example of access key authentication transmitted in the HTTP header.

In addition, there are more sophisticated key authentication schemes for unprotected connections. In this case, the key usually consists of two parts: public and secret. The public part is used to identify the client, and the secret part allows you to generate a signature. For example, by analogy with the digest authentication scheme, the server can send a unique nonce or timestamp value to the client, and the client can return a hash or HMAC of this value calculated using the secret part of the key. This avoids the transfer of the entire key in its original form and protects against replay attacks.

Token authentication

This authentication method is most often used when building distributed Single Sign-On (SSO) systems, where one application ( service provider or relying party ) delegates user authentication to another application ( identity provider or authentication service ). A typical example of this method is to log into the application via an account on social networks. Here, social networks are authentication services, and the application trusts the user authentication function to social networks.

The implementation of this method is that the identity provider (IP) provides reliable information about the user in the form of a token , and the service provider (SP) application uses this token to identify, authenticate and authorize the user.
At a general level, the whole process is as follows:

  1. The client is authenticated to the identity provider in one of the ways specific to it (password, access key, certificate, Kerberos, etc.).
  2. The client asks the identity provider to provide him with a token for a specific SP-application. Identity provider generates a token and sends it to the client.
  3. The client is authenticated in the SP application using this token.



An example of authenticating an “active” client using a token sent by the Bearer scheme.

The process described above reflects the authentication mechanism of the active client, i.e., one that can perform a programmed sequence of actions (for example, an iOS / Android application). The browser is a passive client in the sense that it can only display pages requested by the user. In this case, authentication is achieved by automatically redirecting the browser between the identity provider and the service provider web applications.


An example of authenticating a "passive" client by redirecting requests.

There are several standards that precisely define the protocol of interaction between clients (active and passive) and IP / SP-applications and the format of tokens supported. Among the most popular standards are OAuth, OpenID Connect, SAML, and WS-Federation. Some information about these protocols is in the article below.

The token itself is usually a data structure that contains information about who generated the token, who can be the recipient of the token, the duration, the set of information about the user (claims). In addition, the token is additionally signed to prevent unauthorized changes and guarantees of authenticity.

When authenticating using a token, the SP application must perform the following checks:

  1. The token was issued by a trusted identity provider application (field check issuer ).
  2. The token is assigned to the current SP application ( audience field check).
  3. The validity of the token has not yet expired (checking the expiration date field).
  4. The token is authentic and has not been changed (signature verification).


In case of successful verification, the SP-application authorizes the request based on the user data contained in the token.

Token Formats

There are several common token formats for web applications:

  1. Simple Web Token (SWT) is the simplest format, which is a collection of arbitrary name / value pairs in the HTML form coding format. The standard defines several reserved names: Issuer, Audience, ExpiresOn and HMACSHA256. The token is signed with a symmetric key, so both IP and SP applications must have this key in order to be able to create / verify a token.

    An example of a SWT token (after decoding).
    Issuer = http: //auth.myservice.com&
    Audience = http: //myservice.com&
    ExpiresOn = 1435937883 &
    UserName = John Smith &
    UserRole = Admin &
    HMACSHA256 = KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

  2. JSON Web Token (JWT) - contains three blocks separated by dots: header, set of fields (claims) and signature. The first two blocks are presented in JSON-format and are additionally encoded in base64 format. A set of fields contains arbitrary name / value pairs, and the JWT standard defines several reserved names (iss, aud, exp, and others). The signature can be generated using both symmetric encryption algorithms and asymmetric ones. In addition, there is a separate standard for writing the format of an encrypted JWT token.

    An example of a signed JWT token (after decoding 1 and 2 blocks).
    {"Alg": "HS256", "typ": "JWT"}.
    {“Iss”: “ auth.myservice.com ”, “aud”: “ myservice.com ”, “exp”: “1435937883”, “userName”: “John Smith”, “userRole”: “Admin”}.
    S9Zs / 8 / uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY


  3. Security Assertion Markup Language (SAML) - defines tokens (SAML assertions) in XML format, including information about the issuer, the subject, the necessary conditions for checking the token, a set of additional statements about the user. SAML tokens are signed using asymmetric cryptography. In addition, unlike previous formats, SAML tokens contain a mechanism to confirm ownership of a token, which helps prevent tokens from intercepting through man-in-the-middle attacks when using unprotected connections.


SAML standard

The Security Assertion Markup Language (SAML) standard describes the interaction methods and protocols between an identity provider and a service provider for exchanging authentication and authorization data through tokens. Initially, versions 1.0 and 1.1 were released in 2002–2003, while version 2.0, which significantly extends the standard and is backward incompatible, was published in 2005.

This fundamental standard is quite complex and supports many different systems integration scenarios. The main "building blocks" of the standard:

  1. Assertions is a proprietary SAML token format in XML format.
  2. Protocols - a set of supported messages between participants, among which is a request to create a new token, retrieve existing tokens, log out, manage user identities, and others.
  3. Bindings are mechanisms for transmitting messages through various transport protocols. Methods such as HTTP Redirect, HTTP POST, HTTP Artifact (link to messages), SAML SOAP, SAML URI (address of receiving the message) and others are supported.
  4. Profiles are typical use cases of the standard, defining a set of assertions, protocols and bindings necessary for their implementation, which allows to achieve better compatibility. Web Browser SSO is one example of such profiles.


In addition, the standard defines the format of the exchange of meta-information between the participants, which includes a list of supported roles, protocols, attributes, encryption keys, etc.

Consider a brief example of using SAML for the Single Sign-On script. The user wants to access the protected resource of the service provider (step # 1 in the passive client authentication diagram). Since the user was not authenticated, SP sends him to the identity provider site to create a token (step # 2). The following is an example of an SP response, where the latter uses SAML HTTP Redirect binding to send a token request message:



In the case of such a request, the identity provider authenticates the user (steps # 3-4), and then generates a token. The following is an example of an IP response using HTTP POST binding (step # 5):



After the browser automatically sends this form to the site of the service provider (step No. 6), the latter decodes the token and authenticates the user. According to the results of the successful authorization of the request, the user gets access to the requested resource (step No. 7).

WS-Trust and WS-Federation Standards

WS-Trust and WS-Federation are part of the WS- * standards group, which describes SOAP / XML-web services. These standards are developed by a group of companies that include Microsoft, IBM, VeriSign, and others. Along with SAML, these standards are quite complex and are used primarily in corporate scenarios.

The WS-Trust standard describes an authorization service interface called the Secure Token Service (STS). This service works under the SOAP protocol and supports the creation, updating, and cancellation of tokens. At the same time, the standard allows the use of tokens of various formats, but in practice, SAML tokens are mainly used.

The WS-Federation standard concerns the mechanisms for the interaction of services between companies, in particular, token exchange protocols. At the same time, WS-Federation extends the functions and interface of the STS service described in the WS-Trust standard. Among other things, the WS-Federation standard defines:



It can be said that WS-Federation allows us to solve the same tasks as SAML, however their approaches and implementation are somewhat different.

OAuth and OpenID Connect standards


Unlike SAML and WS-Federation, the OAuth (Open Authorization) standard does not describe the user authentication protocol. Instead, it defines the mechanism for accessing one application to another on behalf of the user. However, there are schemes that allow user authentication based on this standard (more on this below).

The first version of the standard was developed in 2007–2010, and the current version 2.0 was published in 2012. Version 2.0 considerably expands and at the same time simplifies the standard, but is inversely incompatible with version 1.0. OAuth 2.0 is now very popular and is used everywhere to provide delegated access and third-party user authentication.

To better understand the standard itself, consider an example of a web application that helps users plan trips. As part of the functionality, it is able to analyze users' mail for the presence of letters with confirmations of bookings and automatically include them in the planned route. The question arises, how can this web application safely access mail users, such as Gmail?

> Ask the user to enter their account information? - bad option.
> Ask the user to create an access key? - perhaps, but very difficult.

This is the problem that the OAuth standard solves: it describes how a travel application (client) can access a user's mail (resource server) with the user's permission (resource owner). In general, the whole process consists of several steps:

  1. The user (resource owner) gives permission to the application (client) to access a specific resource in the form of a grant. What is a grant, consider a little lower.
  2. The application accesses the authorization server and receives the access token to the resource in exchange for its grant. In our example, the authorization server is Google. When you call, the application is additionally authenticated using the access key issued to it during pre-registration.
  3. The application uses this token to obtain the required data from the resource server (in our case, the Gmail service).



The interaction of components in the standard OAuth.

The standard describes four types of grants that define possible application scenarios:

  1. Authorization Code - this grant can be received by the user from the authorization server after successful authentication and confirmation of consent to grant access. This method is most often used in web applications. The grant process is very similar to the passive client authentication mechanism in SAML and WS-Federation.
  2. Implicit - used when the application does not have the ability to securely receive a token from an authorization server (for example, a JavaScript application in a browser). In this case, the grant is a token received from the authorization server, and step No. 2 is excluded from the scenario above.
  3. Resource Owner Password Credentials - the grant is a pair of username / password user. It can be used if the application is an “interface” for the resource server (for example, the application is a mobile client for Gmail).
  4. Client Credentials - in this case there is no user, and the application gets access to its resources using its access keys (step 1 is excluded).


The standard does not define the format of the token that the application receives: in the scenarios addressed by the standard, the application does not need to analyze the token, since it is only used to gain access to resources. Therefore, neither the token nor the grant per se can be used to authenticate the user. However, if an application needs to obtain reliable information about a user, there are several ways to do it:

  1. Often, the resource server API includes an operation that provides information about the user himself (for example, / me in the Facebook API). An application can perform this operation every time after receiving a token to identify the client. This method is sometimes called pseudo-authentication .
  2. Use the OpenID Connect standard, developed as a credential layer on top of OAuth (published in 2014). In accordance with this standard, the authorization server provides an additional identity token in step No. 2. This token in the JWT format will contain a set of specific fields (claims) with information about the user.


It is worth noting that OpenID Connect, replacing previous versions of the standard OpenID 1.0 and 2.0, also contains a set of optional add-ons for finding authorization servers, dynamic client registration and user session management.

Conclusion


In this article, we looked at various authentication methods in web applications. Below is a table that summarizes the described methods and protocols:

The way
Main application
Protocols
By password
User Authentication
HTTP Forms
By certificates
User authentication in secure applications; service authentication
SSL / TLS
By one-time passwords
Additional user authentication (to achieve two-factor authentication)
Forms
By access keys
Authentication of services and applications
-
By tokens
Delegated user authentication; delegated application authorization
SAML, WS-Federation, OAuth, OpenID Connect


I hope that the information was useful, and you can apply it in the design and development of new applications. See you again!

Author : Dmitry Vyrostkov, Solutions Architect in DataArt.

Source: https://habr.com/ru/post/262817/

More articles:


All Articles