What is token authentication?

Via token authentication features, users can implement access control via URL parameters or HTTP request headers without having to build complex back-end systems

Take mlytics platform as an example, we will check these tokens at the Web Application Firewall (WAF) before any request is relayed to an origin. If the token is not valid the request is blocked. Since mlytics handles all the token validation, the origin server does not need to have complex authentication logic. In addition, a malicious user who attempts to forge tokens will be blocked from ever reaching the origin.

Why do we need token authentication?

  • API Protection – Today most applications are client software that connects to HTTP based APIs on the Internet. Protecting those APIs from malicious use is important as it’s possible to write client software, such as bots, that talks directly to the APIs bypassing the original application. This can lead to abuse and unwanted load on API servers.

  • WebSocket Services – WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C. WebSocket is a different protocol from HTTP but carry in the HTTP layer. It is widely used in many web applications that need real-time and full-duplex client/server communication, such as a p2p game, industry bots like flying drone remote control, etc. Token authentication can be used to validate that an API or WebSocket request is coming from a valid user, client or a mobile device on the edge. mlytics will filter out non-authenticated or forged requests and not pass them on to the origin API server.

  • Other scenarios – Token authentication can be considered as kind of Access Control Mechanism. It can be used to control access for your web resources like internal documents, non-referable links especially static assets like images, PDFs, zip files, apps, eBooks, and other downloadable content.

Token authentication methods

Token Authentication leverages tokens to verify that a user has access to a specific resource. The token can be sent as a URL parameter or in an HTTP header. Below are three widely used token authentication method:

  •  Key authentication – A key either in a query string parameter or a header to authenticate their requests. The token of key authentication is generated from the following:
    • A secret (the key) shared between mlytics and the API or WebSocket.
    • The path to the WebSocket or APIThe mlytics WAF validates the token and allow access or not based on the result. The WAF simply just verify if the signed URL’s key is identical with WAF’s.

  • HMAC authentication – HMAC Signature authentication. This method will validate the digital signature sent in the Proxy-Authorization or Authorization header (in this order). The implementation is based on the draft-cavage-http-signatures draft with a slightly different signature scheme. The token is an HMAC generated from the following:
    • A secret shared between mlytics and the API or WebSocket
    • A Unix epoch timestamp
    • Potential optional additional parameters (e.g. IP address, the cookie value, username); The mlytics WAF validates the token and allow access or not based on the result. The generated HMAC can also be configured to expire after a certain time (e.g. 10 minutes), or so that the expiry is controlled directly from the origin server. In the latter case, the generated URLs would simply include an absolute future Unix timestamp.

  • JWT authentication – Verify requests containing HS256 or RS256 signed JSON Web Tokens (as specified in RFC 7519). Each of your API or WebSocket will have JWT credentials (public and secret keys) which must be used to sign their JWTs.

    mlytics will either proxy the request to your upstream services if the token’s signature is verified or discard the request if not. mlytics can also perform verifications on some of the registered claims of RFC 7519.
    • A secret shared between mlytics and the API or WebSocket
    • Algorithm: The algorithm used to verify the token’s signature. Can be HS256, HS384, HS512, RS256, or ES256.
    • RSA_public_Key: If the algorithm is RS256 or ES256, the public key (in PEM format) to use to verify the token’s signature.
    • Potential optional additional parameters as payload (e.g. IP address, cookie value, username);

Implementation of token authentication

Implementation of token authentication can be done via few steps. Let’s take JWT authentication as an example:

const jwt_key = "yourjwtkey"
const jwt_secret = "yourjwtsecret"

var jwt = require('jwt-simple')
var uuid = require('uuid')

function genJWT(user_fields) { 
    var payload = { 
        iat: (new Date().getTime() / 1000), 
        jti: uuid.v4(), 
        iss: jwt_key, 
        user_fields: user_fields 
    } 
    var token = jwt.encode(payload, jwt_secret) 
    return token
    } //end gen jwt

var user_fields = { 
    customer: 'mlytics', 
    }

var token = genJWT(user_fields)
var link = 'yoururl?jwt=' + token;

Token authentication feature will soon be available on mlytics.

Types of attacks token authentication can prevent

  • Replay attack – A replay attack (also known as playback attack) is a form of network attack in which valid data transmission is maliciously or fraudulently repeated or delayed.

    Another way of describing such an attack is: “an attack on a security protocol using a replay of messages from a different context into the intended (or original and expected) context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run.”Prevent Replay Attack on Token Authentication Message is a critical factor of successful implementation. Prevention and countermeasures:
    • Timestamps
    • One-time Password
    • Session Identifier
    • Other User Field VerificationThe mlytics WAF validates the token and allow access or not based on the result. The WAF simply just verify if the signed URL’s key is identical with WAF’s.

  • Clock skew – The HMAC /JWT authentication also implements a clock skew check as described in the specification to prevent replay attacks. By default, a minimum lag of 300s in either direction (past/future) is allowed. Any request with a higher or lower date value will be rejected. The server and requesting client should be synchronized with NTP and a valid date (using GMT format).

Related posts