Skip to main content Skip to complementary content

JWT authentication

JSON Web Token (JWT) is an open standard for secure transmission of information between two parties as a JavaScript Object Notation (JSON) object. JWT is used for authentication and authorization. Because JWT enables single sign-on (SSO), it minimizes the number of times a user has to log on to cloud applications and websites.

JWT structure

A JWT consists of three parts: a header, a payload, and a signature.

Header

The header usually consists of two parts: type (typ) and algorithm (alg). The algorithm is used to generate the signature.

Example:  

{

"typ": "JWT",

"alg": "RS256"

}

RS256 indicates that RS256 - RSA signature with SHA256 is used to sign this token.

Payload

The payload is a JSON object that consists of the claims that you want to make. Claims are statements about an entity (usually the user) and additional metadata.

Example:  

{

"userId":"jde",

"name":"John Donne",

"email":"jde@company.com",

"roles":["RootAdmin"],

"exp": 1472034208

}

Signature

The signature is used to verify the identity of the JWT sender and to ensure that the message has not been tampered with. The signature is the encoded header and payload, signed with a secret key. In the normal case, X.509 certificates are used to generate and validate the signature. In the virtual proxy in the QMC, the certificate, including the public key, is configured to validate the signatures.

Authentication is performed by verifying the signature. If the signature is valid, access is granted to Qlik Sense.

Supported signature algorithms

The following signatures are supported in Qlik Sense:

  • RS256 - RSA signature with SHA256

  • RS384 - RSA signature with SHA384

  • RS512 - RSA signature with SHA512

Example: Accessing Qlik Sense with a signed JWT

The following example shows the steps involved when gaining access to Qlik Sense by using a signed JWT.

The client uses a signed JWT as the Authorization: Bearer value inside of HTTP headers to connect to a proxy. The proxy then connects to a backend service in Qlik Sense.

  1. A JWT is generated, including a set of claims, and is signed with the private key for the configured certificate.

  2. A request is sent to the proxy including the signed JWT in the HTTP Authorization header.

  3. The proxy validates the signature of the JWT using the public key from the configured certificate.

  4. The proxy injects the Qlik Sense headers including the configured attribute mappings and forwards the call to the backend service.

  5. The client will receive a session and subsequent calls are not required to include a JWT.

    1. If the calls do include a JWT it will be validated, and if it is invalid the user will be rejected access.
    2. If the user in the JWT is different from the user stored for the session, the user will obtain a new session.

Standard fields

The following fields can be used inside a JWT claim:

  • Issuer (iss): identifies the principal that issued the JWT.
  • Subject (sub): identifies the subject of the JWT.
  • Audience (aud): identifies the recipients of the JWT.
  • Expiration time (exp): identifies the expiration time after which the JWT is not accepted.
  • Not before (nbf): identifies the starting time on which the JWT is accepted.
  • Issued at (iat): identifies the time at which the JWT was issued.
  • JWT ID (jti): identifies the token.

Limitations

The following limitations exist:

  • Encrypted JWTs are not supported.

    Information noteWhen using HTTPS, all traffic, including JWTs, are encrypted during transport.
  • Only the following signing algorithms are supported:

    • RS256 - RSA signature with SHA256

    • RS384 - RSA signature with SHA384

    • RS512 - RSA signature with SHA512

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!