JWT SSO for Private Content - Invalid Requirements and AWS Cognito Failure


I've raised this to our enterprise support team but they have now suggested that I waste more of my time solving HubSpot's bugs by asking me to come post here.


What this issue really higlights for me is that HubSpot has no effective bug reporting process. Reps in support should be empowered to report bugs to engineering rather than asking customers to jump through more hoops as though we have lots of free time @dharmesh 


So here is the exact problem... Posted now for a 3rd time because sharing it with support is not a path to resolution:


The JWT SSO parser provided by HubSpot as part of the external authentication mechanism provided here has a bug.


The JWT specification does not require a "type" header and in fact many providers (e.g. AWS Cognito) do not set "type" headers in the JWT token.


When attempting to validate a perfectly valid JWT token which passes all RFC checks for enabling private content access via SSO, HubSpot throws a "Missing Type Header" error.


Requiring a header of "type=jwt" is ridiculous since the token is a JWT token and we have to define the auth type (SAML vs JWT) when setting up the SSO integration. It feels a bit like asking "Are you a consumer of food?" when pulling up to the McDonalds drive through... Um, yes, that is why I'm here instead of at the shoe store.


AWS Cognito headers in the JWT token look like this:



{ "kid": "YX16pm4spq6PosaafI+GtxF22x+kMNcekWL15CD4WTE=", "alg": "RS256" } 




Even the alg field is not necessary if HubSpot is requiring us to specify the encryption algorithm as an option although the alg is part of the spec so that seems odd... You do require a "type" which is not required and you don't require an "alg" which is.


Please upgrade the JWT implementation to respect that not all JWT providers are named Okta.


As well, it would be great if HubSpot didn't redact the "access_token" query string from serverless functions... We coded up a function to rewrite the JWT token but sure enough, we can't access the query string named "access_token" because it is stripped from the context.params before the function runs.


Super frustrating finding bugs. More frustrating being asked to do support's job.

2 Replies 2
Community Manager

Hey @arlogilbert ,

I apologize for the frustration.

I took a look at the ticket that you submitted and it appears that there was some confusion about its state.  I can confirm that the issue is still open and being investigated by our product experts.  I reached out directly to them to confirm.

I will keep an eye on it to monitor the progress.   Feel free to reach out here or to the ticket that you have open.



Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content