Skip to main content

Website Authentication Protocols

Authentication systems is the backbone of many websites. It allow users to login to your site and preserving data between visits. It is crucial in offering a robust user experience which rewards your users for providing their details. Authentications often provide access to personal private data which if made public, it could harm your user. To prevent these, authentication protocols were created to secure the requests while allowing users to still safely login to your system from any environment.

Basic SSL Auth

Basic auth is the simplest form of web authentication. It utilizes standard HTTP headers in place of more complicated solutions that rely on cookies, session identifiers, and login pages. There is very little security built into the basic auth system. Credentials are transmitted with only Base64 encoding and are not encrypted or hashed. Due to the ingrained insecurities in the system, these requests are most often made via HTTPS.

The authorization information should be compiled into a the following format and included in the header:

Format:

<!--Authorization: Basic -->

Full details on the Basic Authentication protocol can be found here: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth works similar to basic SSL authentication with the exception that the password is encrypted using a one-way hash. It utilizes MD5 cryptographic hashing with a nonce(a server generated value that prevents replay attacks).

The typical flow of a Digest Auth request is :

  1. A user navigates to a page that requires the user to be authenticated.
  2. The server responds with a 401 message that signifies that a user is not currently authorized to access the content. In the response it also includes the nonce which will be used during the authorization to prevent replay attacks,
  3. The site then displays an authentication interface in order to gather the required details( username and password )
  4. The provided details are resent to the server with an authentication header included in the request that has a response code.
  5. The server would then verify the provided credentials and accept the authentication or return a 401 message if the credentials are incorrect which would cause the user to be again prompted with the authentication interface.

You can find full details on the Digest Auth protocol can be found here: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

The OAuth 1.0 protocol relies on having a shared secret between the server and site. This shared secret is used to generate a signature that is included in the request. The generated signature is used to verify on server-side the validity of the authentication request. The process for authorizing the user is generally handled in three steps( 3-legged OAuth):

  1. Site obtains Request Token.
  2. User authorizes the Request Token.
  3. Site exchanges Request token for Access Token.

The process of completing a 3-legged OAuth request will generally be handled as follows:

  1. The site will send a signed request for the Request token. This request should contain the following parameters:

    1. oauth_consumer_key
    2. oauth_timestamp
    3. oauth_nonce
    4. oauth_signature
    5. oauth_signature_method
    6. oauth_version
    7. oauth_callback

This request will be validated on the server and if validated will return the request token in the following format:

  1. oauth_token
  2. oauth_token_secret
  3. and any other additional parameters returned by your server.
  4. The next step after retrieving the request token is to prompt your user to input their login credentials. These are then formatted into a signature with the oauth_token request token and sent with a request back to the server for validation. Upon successful validation from this request the server will return the following:
  5. oauth_token
  6. oauth_verifier

These will be used in the next step to retrieve an access token.

  1. The final step is exchanging the retrieved details from step 2 for an access token , which will be used to access the servers resources. To exchange your request token for an access token, you can make a request to the server with the following signed request
  2. oauth_token -returned from step 2
  3. oauth_consumer_key
  4. oauth_nonce
  5. oauth_signature
  6. oauth_signature_method
  7. oauth_version
  8. oauth_verifier -returned from step 2

This will return you an access token to be used in conjunction with your secret in order to make requests for information from the server.

You can find full details on the OAuth 1.0 protocol here: https://tools.ietf.org/html/rfc5849

OAuth 2.0

This is similar to the OAuth 1.0 protocol, it relies on a client id and secret in order to format request, but simplifies much of the complicated signing process that is inherent in the OAuth 1.0 system. The process for authorizing a user using the 3-legged OAuth 2.0 protocol is as follows:

  1. User is directed to the service for authorization with the following details included in the authorization URL:

    1. client_id
    2. redirect_uri
    3. response_type
    4. scope

  2. User would then authenticate with the service and grants the application access to their details. On successful authentication the user is redirect back to the redirect_uri with the following parameters:

    1. code
    2. state

  3. The code returned in step 2 is then used by the application to make a request for an access token. Included in this request should be:

    1. client_id
    2. client_secret
    3. code
    4. redirect_uri
    5. grant_type - This should be set to “authorization_code”

The server will verify these details and then return an access token with an expiration time if they are valid. These are generally returned in the following format:

  1. access_token
  2. expires_in
  3. refresh_token

You can find full details on the OAuth 2.0 protocol here: http://oauth.net/2/

Authentication protocols allow you to secure your data with varying levels of security. Depending on the data being accessed and your desired level of security implementing one of the above protocols allows you to be confident that your data is safe and only being accessed by users that are permitted to your system.

Comments

Post a Comment

Popular posts from this blog

4 Ways to Communicate Across Browser Tabs in Realtime

1. Local Storage Events You might have already used LocalStorage, which is accessible across Tabs within the same application origin. But do you know that it also supports events? You can use this feature to communicate across Browser Tabs, where other Tabs will receive the event once the storage is updated. For example, let’s say in one Tab, we execute the following JavaScript code. window.localStorage.setItem("loggedIn", "true"); The other Tabs which listen to the event will receive it, as shown below. window.addEventListener('storage', (event) => { if (event.storageArea != localStorage) return; if (event.key === 'loggedIn') { // Do something with event.newValue } }); 2. Broadcast Channel API The Broadcast Channel API allows communication between Tabs, Windows, Frames, Iframes, and  Web Workers . One Tab can create and post to a channel as follows. const channel = new BroadcastChannel('app-data'); channel.postMessage(data); And oth...
Post a Comment
Read more

Certbot SSL configuration in ubuntu

  Introduction Let’s Encrypt is a Certificate Authority (CA) that provides an easy way to obtain and install free  TLS/SSL certificates , thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx. In this tutorial, you will use Certbot to obtain a free SSL certificate for Apache on Ubuntu 18.04 and set up your certificate to renew automatically. This tutorial will use a separate Apache virtual host file instead of the default configuration file.  We recommend  creating new Apache virtual host files for each domain because it helps to avoid common mistakes and maintains the default files as a fallback configuration. Prerequisites To follow this tutorial, you will need: One Ubuntu 18.04 server set up by following this  initial ...
Post a Comment
Read more

Working with Node.js streams

  Introduction Streams are one of the major features that most Node.js applications rely on, especially when handling HTTP requests, reading/writing files, and making socket communications. Streams are very predictable since we can always expect data, error, and end events when using streams. This article will teach Node developers how to use streams to efficiently handle large amounts of data. This is a typical real-world challenge faced by Node developers when they have to deal with a large data source, and it may not be feasible to process this data all at once. This article will cover the following topics: Types of streams When to adopt Node.js streams Batching Composing streams in Node.js Transforming data with transform streams Piping streams Error handling Node.js streams Types of streams The following are four main types of streams in Node.js: Readable streams: The readable stream is responsible for reading data from a source file Writable streams: The writable stream is re...
Post a Comment
Read more