Question

Ability to control how pxGenerateJWT put in the header

According to Pega Help:

https://community.pega.com/sites/default/files/help_v82/procomhelpmain.htm#data-/data-admin-/data-admin-security-/data-admin-security-token/generation.htm#Generation_tab_on_the_Token_Profile_form

alg – The used JWS algorithm, which is in the Security section, on the Generation tab.
cty – The content type is populated by default as application/json.
typ – The type is always JWT.
kid – The Key ID is a unique ID generated by the JWT runtime for each token generated.
crit – Headers that are marked as critical on the Generation tab.

Kid is generated every time using pxGenerateJWT. In the example that we have, this is the Header that got generated:

{
"kid": "4a08b9920940f25110d0b49bf937e855",
"cty": "application/json",
"typ": "JWT",
"alg": "RS256"
}

We need to create a JWT to send to a service in order to obtain a token that will be used in calling other services. According to the service provider, their definition of kid is as follows:

  • KID is the public key thumbprint. It is generated by the toolkit(nimbus) we use to generate/validate assertions.

The service provider also considers the KID header parameter optional. We have tested with a hand crafted JWT created using jwt.io, and have confirmed that the KID header parameter made a difference. And the service provider accepts the JWT without KID in the header.

We would like to find out the steps to achieve at least one of the following:

1) Generate KID based on the public key thumb print

2) Allow the developer to decide how KID is generated

2) Suppress the generation of KID altogether

***Edited by Moderator Marissa to update SR Details***

Group Tags

Comments

Keep up to date on this post and subscribe to comments

July 24, 2019 - 12:02pm

Options 2 & 3 are enhancements.

As for #1, I believe that is what Pega does. The certificate needs to be provided by the service provider. I've seen an issue debugged where the JWT generated by Pega was failing and the issue was cleared up by making sure both the SP and Pega were using the same certificate - from which, Pega obtains the public key thumbprint and uses it to generate. 

The Pega help document reference of " ... JWT runtime " is in fact referring to the same toolkit the service provider is mentioning. This is from the Pega ThirdPartyLicense PDF distributed with the product.

 

July 24, 2019 - 1:24pm
Response to PaulGentile_GCS

Paul,

On the Pega side, we have the Keystore data instance.  And on the Service Provider side, they have the Public Key.  

I handcrafted a JWT in jwt.io by replacing the kid parameter generated by Pega with a thumbprint from Java code below:

    com.nimbusds.jose.util.Base64URL thumbprint = rsaPublicJWK.computeThumbprint();

And now the JWT is accepted by the Service Provider.

 

 

July 24, 2019 - 3:48pm
Response to TerenceY0215

Just want to reiterate, without the ability the suppress kid generation, or be able to specify the kid value, it still does not work for us.  The preferred way is to suppress kid generation.