Access Fabric Signed Headers

The ScaleFT Access Fabric includes a signed JWT in a header on every request that it forwards to protected applications. By validating this header applications can ensure that they only accept traffic which has been verified by the Access Fabric.

Note: Signed headers are the only way to validate that a request actually comes from the Access Fabric, so validating these is critical to securing any application deployed behind the Access Fabric.

Header Validation Using a Proxy

The safest and easiest way to validate signed headers from the Access Fabric is to use a compatible proxy such as:

Custom Header Validation

JWT Contents

Every request forwarded to your application by the Access Fabric will contain a header called Authenticated-User-Jwt. The contents of the header are a signed JSON Web Token containing claims such as:

  "aud": [
  "email": "",
  "exp": 1512465111,
  "iat": 1512464931,
  "iss": "",
  "nbf": 1512464811,
  "sub": "b0c67ec4-da3c-41a2-b8a7-92043defcb14"

In order to validate the token an application must:

  1. Parse the JWT
  2. Load the public key needed to validate the JWT
  3. Check the signature of the JWT against the public key
  4. Validate that the claims in the JWT match what is expected

See here for a list of JWT validation libraries.

Public Keys

The public keys needed to validate signed JWTs from the Access Fabric are available as a JSON Web Key Set at the following URL:

In order to select a public key, you will need to:

  • Select the public key from the above URL whose kid matches the kid paramter in the JWT’s header
  • Confirm that the alg field on the selected public key matches the alg paramter in the JWT’s header
Claim Validation

After verifying the signature on the JWT, you must verify the contents of the following claims:

  1. iss should always be
  2. nbf should be a unix timestamp which is less than or equal to the current time
  3. exp should be a unix timestamp which is greater than the current time
  4. aud should contain your Access Fabric Application URL (for example,
Other Claims

After validating the claims described above, your application may make use of the following claims:

  • sub is an opaque string which uniquely identifies the user accessing the application
  • email is a string containing the email address of the user accessing the application