"token contains an invalid number of segments"

Question

I am seeing this error when I try to hit endpoint using postman:

{
    "errors": [
        "token contains an invalid number of segments"
    ]
}

Console:

TypeError: Cannot read property 'jwt' of undefined

Answer 1

The question is a bit vague, but in this case - TypeError: Cannot read property 'jwt' of undefined.

The object that should have the property jwt, is undefined. So the token itself doesn't exist, and neither does the object that is supposed to hold it.

More generally, this error may occur if the token is malformed.
It should have 3 segments, like this [separated by . ]-

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Each of those segments can be decoded by base64 to inspect the header, payload, and signature.

Which results in this -
from - https://jwt.io/

More information from https://www.ibm.com/docs/en/cics-ts/6.1_beta?topic=cics-json-web-token-jwt

Header
The header typically consists of two parts: the type of the token, which is JWT, and the algorithm that is used, such as HMAC SHA256 or RSA SHA256. It is Base64Url encoded to form the first part of the JWT.

Payload
The payload contains the claims. There is a set of registered claims, for example: iss (issuer), exp (expiration time), sub (subject), and aud (audience). These claims are not mandatory but recommended to provide a set of useful, interoperable claims. The payload can also include extra attributes that define custom claims, such as employee role. Typically, the subject claim is used to create the OpenID Connect user subject. However, the Liberty JVM server can be configured to use an alternative claim. The payload is Base64Url encoded to form the second part of the JWT.

Signature
To create the signature part, the encoded header and encoded payload are signed by using the signature algorithm from the header. The signature is used to verify that the issuer of the JWT is who it says it is and to ensure that the message wasn't changed along the way.

More information about the spec here -
https://datatracker.ietf.org/doc/html/rfc7519#page-7