Base64 encoding incorrectly applied to application/jwk-set+json

[jeremyhewett]

It seems the adapter treats a response with Content-Type header application/jwk-set+json as binary and base64 encodes it. The response should actually be plain JSON.

Specific scenario: I'm deploying an application based on node-oidc-provider, and the /jwks endpoint returns a base64 encoded string instead of plain JSON. The Content-Type header set by node-oidc-provider is application/jwk-set+json which is not configurable (and is apparently the correct value for this response). When I do change it to application/json (with a hack), then I get the correct response in plain JSON.

[bnusunny]

Which version of the adapter did you see this problem? The adapter relies on lambda-http crate from AWS Lambda Rust Runtime to processing the response. lambda-http crates does treat "+json" suffix as text. Here is the link to the code.

And as related note, lambda-http crate won't be able to cover all text based contexn-types. In v0.8.0, lambda-http treats the following content-types as text.

Prefixes:

• "text"
• "application/json"
• "application/javascript"
• "application/xml"
• "application/yaml"

Suffixes:

• "+xml"
• "+yaml"
• "+json"

For other content-types, lambda-http will treat them as binary data and base64 encode it. And if you use API Gateway REST API to trigger the Lambda function, you need to configure binaryMediaTypes to handle the binary response. Details are in API Gateway Developer guide here.

[mluksch]

Same here with graphql-yoga + nextjs. With "Content-Type"-Response Header: "application/graphql-response+json; charset=utf-8". Is the charset a problem here maybe?

[bnusunny]

Oh, the charset part causes the issue. This code here assumes Content-Type ends with the media type, which is not true.

I will fix this issue in Rust Runtime first.

[mluksch]

Awesome. Thank you :)