Supporting a JWS token encoded with BASE64

[igsong]

Currently, AWS ALB makes a JWT token with base64 (not base64url encoding). Since node-jws very strictly checks the format of a token, the JWT token made by ALB cannot pass verification. As a workaround, I added an option "base64". If the "base64" option is true, characters used in the base64 encoding are checked instead of it of the base64url encoding.

[gdamjan]

from what I see from my AWS ALB headers, the x-amzn-oidc-data token has also _ and - and = characters.

I've fixed my problem by just adding = to the third component in JWS_REGEX

[omsmith]

I've reached out to AWS, will follow up.

[omsmith]

In the mean time, I don't plan to accept this PR and don't want to lead you on. I'll continue poking AWS and let you know.

See: https://github.com/brianloveswords/node-jws/issues/49

[joetjef]

I just got an update from AWS:

We moved to base64url, but were still padding at the end. We are currently deploying a fix to remove the padding. It will be available globally in the coming weeks.

[joaovieira]

@omsmith @joetjef any updates from AWS on this? Just bumping into this issue and unable to progress.

Allowing the padding with:

-var JWS_REGEX = /^[a-zA-Z0-9\-_]+?\.[a-zA-Z0-9\-_]+?\.([a-zA-Z0-9\-_]+)?$/;
+var JWS_REGEX = /^[a-zA-Z0-9\-_=]+?\.[a-zA-Z0-9\-_=]+?\.([a-zA-Z0-9\-_=]+)?$/;

Solves everything. (Yeah, I've read through https://github.com/brianloveswords/node-jws/issues/49).

The workaround is pretty ugly and duplicates everything from jsonwebtoken's verify logic.

[kevoriordan]

Any update on this from AWS? We've also ran into the issue on our end. AWS support are saying "working as designed".

[panva]

~Correct me if i'm wrong, but since AWS fixed to use base64url instead base64 and only left the padding in, you should be able to just strip the padding from the tokens you're receiving (all the = characters) and it should validate.~

[amarrella]

@panva : yes, you can just strip the padding but the signed value changes and the signature becomes invalid, so if i'm passing the token upstream to other services either:

• i pass the padded value (and they need to implement the removal logic too) :(
• i pass the non-padded value, but the signature doesn't validate, so i either re-sign it (and i need to host a CA) or i strip the signature and set the alg to none, which some libraries might still reject

[panva]

Ah right, the signed value is not the binary contents but the serialized one 🤦‍♂. Ignore my comment. AWS should fix this if they claim what they produce is a JWT. base64url with padding is not a valid JWT/JWS.

[pjaol]

June 2020 - I've come across this padding issue in numerous AWS area's not just JWT response has been 🤷 Potentially will break stuff down stream, but 3 years of fighting the system isn't working. If the suggested for handling padding works, please accept it. Otherwise allow for users to provide their own parsing method without having to fork the code. Better to provide options than nothing at all

[t0rr3sp3dr0]

AWS response to the issue in November 2020:

Hello,

Thank you for contacting AWS support. My name is Juan and I have taken ownership of this case to further assist you.

I understand you have an ALB with the x-amzn-oidc-data header which contains padding and if you remove the characters behind "=" the token, it becomes invalid.

This issue is known inside of AWS and the padding cannot be removed at this time as it is intentional per our public documents. [1]

Looking at precedent cases on this topic, the internal teams have recommended to adjust your back-end code to take the padding into account while it parses the token, and then send the token upstream unsigned. Because the load balancer does not encrypt the user claims, we recommend that you configure the target group to use HTTPS. If you configure your target group to use HTTP, be sure to restrict the traffic to your load balancer using security groups.

There is currently a feature request for this in the works, but there is not ETA when this feature will occur.

I have found an article which may or may not assist you with the authentication in your environment from a third party source: https://zdenek-papez.medium.com/istio-authorization-using-okta-user-groups-in-jwt-claims-behind-aws-application-load-balancer-191f26779cad

We do apologize for any inconvenience this issue may have caused you.

I trust the information provided is helpful. Please feel free to reach out to me if you have further questions or concerns.

[1] https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding

We value your feedback. Please share your experience by rating this correspondence using the AWS Support Center link at the end of this correspondence. Each correspondence can also be rated by selecting the stars in top right corner of each correspondence within the AWS Support Center.

Best regards, Juan E. Amazon Web Services

[pjaol]

Build bugs and ignore standards

[tannert44]

Since this is a known issue and you guys cannot get it fixed within 2 years, why don't you guys add more than a single sentence in the documentation that explains in more detail what issues a developer is going to run into when it comes to decoding the JWT.

All your public documentation mentions is that it has padding characters, it doesn't mention that you guys are not actually following proper standards when it comes to JWT tokens, and so the libraries your documentation recommends else where at places like jwt.io will not actually work as intended. This cost me hours and hours of my time.