0
votes

I am developing an integration client for a web-service which is based on content-type = application/jose.

It means I have to send the message body in terms of JWS / JWT. Now, I have reviewed about JWS and JWT and found that it comprises of Header that will contain the algorithm details, a Payload that will contain the payload to be transferred but I haven't seen any example on the internet where actual payload is encoded in JWT? I only see fields like sub, iat, date time etc..

I want to know, that if my request body in terms of decoded JSON is:

{
"instruction_id": "1",
"account_code": "1234",
...
...

}

Then in this case, what will the payload be? I haven't found any big difference between JWS and JWT they both comprises of header, payload and signature (applied using private or public key on header.payload).

Can someone elaborate their actual difference? and respond to my payload query above?

1
But the exposing party has provided us the document in which It has been written that we have to pass JWS with each API request. In the samples of requests and responses it has shown us decoded JSON but expect to encode it as JWT/JWS cryptogram while sending. Please suggest - Jawad-Dev
Sorry, I completely overlooked your application/jose requirement. - jAC
Can you please help me? :) - Jawad-Dev
payload: you can basically put into the payload whatever you want, as long as it is in JSON format. Regarding JWT vs. JWS: stackoverflow.com/questions/27640930/… - jps
Then what are these components in payload? ias, sub, iss, exp. It is mandatory to put them too? - Jawad-Dev

1 Answers

0
votes

JWT stands for "Json Web Token" and it represent some form of authentication to grant an application to consume some resource on behalf of an end user.

Because of that you see those claims "sub": (subject) the final user, "exp": (expiration) the expiration time, "aud": the resource server intended to recieve this token, "iss": (issuer): the auth server that creates the token, iat: (issued at): the time when the token was created .. etc there all standard claims that represent something when talking about authorization/authentication. Anyway, you can add other custom claims you consider necessary

But the problem I think is that your use case is different probably it has more to do with JWE than JWT. Respect with JWS is the standard to represent the signature