Skip to content

Authentication and the Web

Having introduced the concepts of Authentication and Authorisation, lets take a look at how they are commonly implemented.

Built in HTTP Authentication

HTTP has a built in framework for authentication, defined in RFC 7235. This is a Challenge -> Response based authentication process, where the server asks the user to supply information (a password) to verify who they are.

The Flow goes something like this

  1. User Requests a restricted page from the server
  2. Server responds with a 401 status code, the response header which WWW-Authenticate includes details the authentication type used (the challenge)
  3. The client can respond with a new request including an Authorization header with the required secret. (For example Basic ZmxhZzo1MDY3e0ZsYWdzRXZlcnl3aGVyZX0=)
  4. The Server checks the credentials and responds with either 200 OK or 403 Forbidden.

HTTP Authentication

Note

The browser needs to send the Authorization header for each page that is protected by HTTP Authentication. This means that credentials are usually cached to avoid the user having to enter them for each page. Caching mechanisms depend on the browser.

There are several different Authentication methods used the most common are:

Basic Authentication

The browser sends a Base64 Encoded string of <username>:<password> to the server in the authorisation header.

For Example:

  • For the username dang and password swordfish
  • The encoded string is: dang:swordfish
  • B64 encoded string becomes: ZGFuZzpzd29yZGZpc2g=
  • The Header Authorization: Basic ZGFuZzpzd29yZGZpc2g= gets sent to the server

Digest Based

Digest Based authentication, tries to work around the weak encoding of the password using hashing

  • As part of the challenge, a nonce (Number used ONCE) value is generated and sent by the server (think of this like a salt)
  • For the response, the message sent is the MD5 of the credentials, and the nonce

As a new nonce is generated for each request, it helps protect the scheme against Replay attacks. The server will only authorise the page if the correct value is generated. However, it can add overhead to the process, as extra requests need to be sent to transmit the nonce value.

While HTTP based methods can give us a reasonably quick and easy way of authenticating users, we need to take into account the way the passwords are sent, as there is no encryption (or weak encryption in the case of digest) on the secrets. If we are using an unencrypted HTTP connection, then the authentication headers will be visible in "plain text"

Is HTTP Authentication useless?

Because of its unencrypted nature, HTTP authentication is often viewed as weak.

Discuss your views on the aula.

- Is it stronger or weaker than the more common "forms" based authentication
- What about Digest based authentication.

Local 1 Authentication

Probably the most common form of authentication we will come across, this is where the authentication process is handled by the server itself. As the ways of actually implementing this form of authentication depend heavily on the application, we will keep the discussion at a high level. Specific issues with the methods will be discussed later in the module.

This is another challenge -> response style of authentication that requires a user to "login" to view or interact with parts of the site. The Login process requires some form of Session Management which we will discuss in the next article.

  1. An Unauthenticated user is shown a page is with a Login Form.
  2. User completes the form and the data is sent to the server
  3. Server checks the users information, if the login is successful a record is made showing the user is authenticated

The method of checking the users credentials will vary from site to site, however it will usually involve checking the details against a record in a database, and keeping track of whether a user is authenticated or not will tend to use some form of session management.

Important

There are lots of things to bear in mind when implementing authentication in this way.

  • The forms will send data to the server in plain text, so using HTTPs is required to keep the details safe from being intercepted
  • There can be issues with Replay attacks is the user can get hold of the credentials
  • How we store user credentials in the database can have a significant impact on the security in case of a breach.

Token based Authentication

Token based authentication is commonly used for API's. In this case rather than authenticate with a traditional password, a user is provided with an access token. As long as the token remains valid, it can be used to authenticate for access to the service.

Tokens are generally issued in two ways.

  • Session tokens where the user requests access to the service at the start of each session. They then go through an authentication process and are issued a token confirming authentication and authorisation details that session. The authentication process could involve a traditional password based approach, or could be something like OAuth.

  • Persistent API tokens tend to be issued by REST like web API's. Lets say you are developing an web application using maps generated through the Mapbox (mapbox.com) API. As part of the sign up process your app will be issued an Application Key to authenticate you with the Mapbox servers.

The key difference between the Access Token types is the lifetime. An API token is intended to grant an APP or similar web service access to a service, and therefore doesn't usually need to be replaced. On the other hand, A Session token on the other hand is intended to replace a more traditional login session.

Sending Tokens to the Server

We also have several different ways of sending tokens to a web server. This is mostly down to implementation choice, but methods can include

  • "Hidden" as part of a form. This means that the token may be part of the URL in the case of a GET request.
  • Stashed in a URL as part of the Query String.
  • Placed inside request headers.

When placed as part of a form, or as a query string the token will be reasonably obvious. Having a URL like www.secret.org?token=Gd2sFsj, or a similar value in the request body gives us a clue to the token value.

The request header fields can vary. Examples include X-Parse-REST-API-Key Again, if we can get access to the request data, then we may be able to re-use the authentication token.

3rd Party Authentication

Rather than storing users authentication details locally on the server, we could also make use of 3rd party authentication methods. This has some benefits when it comes to managing data, as in the case of a breech a users credentials are not compromised. However, it does push the responsibility for maintaining confidentiality onto the 3rd party.

3rd Party authentication includes services such as:

  • OAuth
  • Open ID
  • SAML

While the technical details of the implementation differ, the concept is the same for each provider. We pass the request for authentication across to the 3rd party, and receive a confirmation (and possibly an identification token) of the users identity.

Summary

In this article we have had a quick look at common Authentication methods for web pages. We covered the built in HTTP based authentication, Local Authentication, and gave an overview of 3rd party authentication methods.

While there are many ways of implementing authentication, with it seeming like each service or API takes its own approach, the basic concept is still the same, regardless of whether it is HTTP Basic, or OAuth. We have some sort of challenge is made to the client who then responds. If the response to the challenge is successful, the server makes a record (or issues a token), that is used in future requests.

Regardless of the method used, we should bear in mind that by default HTTP is plaintext. We could have the most secure token generation system in the world, but if an attacker is able to intercept and re-use the login credentials, or token, our authentication system is compromised. For this reason it is best practice to only transmit authentication information using HTTPS.

In the next article we will look how websites keep track of users through Sessions and Session Management.

  1. Not actually sure what to call this, Local works for the moment ↩

Back to top