Janua’s CTO sharing tips and tricks about OpenID and understanding JWT and signed JWT usage with RedHat SSO Keycloak

1) JWT token presentation
JWT token representation is described in RFC 7519

A JWT token is made up of 3 parts , each of them separated by a column “.” It is of the form:

  • header.payload.signature

Header and payload are base 64 encoded, and can easily be deciphered

1.1) Header:
consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.


1.2) Payload
It contains the claims. Claims are statements about an entity (typically, the user) and additional metadata.


1.3) Signature

1.3.1) case of HMAC algorithm – message not compromized – symetric algorithm
The signature is used to verify the message wasn’t changed along the way

In case of secret key, the siganeture is computed as follows, case of HMAC algorithm:

HMAC signature does not garantee the proof of the user who has created the token.
It only indicates that teh JWT token has not been tampered with (i.e not compromized)

1.3.2) case of RSA – message not compromized – non repudiation – asymetric algorithm

As the token is signed with a private key, it can verify with the public key that the sender of the JWT is who
it says it is

It means that you need to get hold of the public key
The algorithm used is much slower than symetric algorithm (about 1000 times slower)

2) openid connect

2.1) id_token – jwt format
The openid spec defines id_token which are delivred in response to a openid request.
id_token format is JWT, which means it is exactly what has been described in previous section.
It contains fields which are defined by the openid specification

2.2) using jwt.io debugger to decipher an jwt token

The jwt.io debugger is aavailable at http://jwt.io

It is possible to display the validate very quickly and to get a grap of an an_token or JWT token using jwt.io debugger



The signature cannot be verified here, as the public key used the along the private key has not been provided in this example
Hence it is indicating the error message seen here.

3) RH-SSO/Keycloak and JWT Token

RH-SSO/keycloak provides out of the the shelve HMAC and RSA algorithm when dealing with JWT token.

HMAC (symetric algoritm) is quite convenient and handy to use, but does not provide non repudiation

RSA (asymetric algoritm) does provide non repudiation, but is a much more slowers algorihtm
The user needs to get hold of the public key certificate to verify the signature

It is up to the the user to decide what is the feature teh most critical to him when dealing with JWT token: speed or non repudiation.

ECC (asymetric alogoritm) is more efficient than RSA but is not yet supported by RH-SSO/keyclaok

Olivier Rivat

Olivier Rivat

Senior Software Engineer with over 25 years of experience doing Software Development, Support and Consulting in Identity and Access Management Solutions.
Specialised in IAM (security, access control, identity management) and Open Source integration, settled in 2004 by IAM industry veteran, JANUA offers high value-added products and services to businesses and governements with a concern for Identity Management and Open Source components.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
Olivier Rivat