Can't decrypt JWE tokens

[Timdebo]

Hello, I have been trying to use JWE tokens for a while now but it's not working, thought it was easy since JWS worked perfectly but I keep getting the same error no matter what I do.

• First, I created an encryption key and stored it (for now) as a plain String in application.properties using this method:

public String getSecretKey() {
        SecretKey key = Jwts.ENC.A256GCM.key().build();
        return Encoders.BASE64.encode(key.getEncoded());
    }

• Then used it for creating JWE tokens for email verification (OTP is stored inside the token, so it must be encrypted):

...
private final SecretKey encryptionKey;
...
@Value("${jwt.encrypt-key}") String encryptKey
...
encryptionKey = new SecretKeySpec(Decoders.BASE64.decode(encryptKey), "AES");
...

• Created the following method for token generation (this worked fine, getting the token when running it with no issue):

public String generateEmailToken(String subject, String otp) {
        return Jwts.builder()
        .issuer("My App")
        .subject(subject)
        .issuedAt(new Date(System.currentTimeMillis()))
        .expiration(new Date(System.currentTimeMillis() + emailDuration.toMillis()))
        .claim("otp", otp)
        .encryptWith(encryptionKey, Jwts.ENC.A256GCM)
        .compact();
    }

• Now the issue arises when trying to parse / validate the token:

public Claims validateEmailToken(String token, String otp) {
        try {
            return Jwts.parser()
            .decryptWith(encryptionKey))
            .requireIssuer("My App")
            .require("otp", otp)
            .build()
            .parseEncryptedClaims(token)
            .getPayload();
        } catch (JwtException e) {
            System.out.println("\n\nNot trusted!\n\n" + e.getMessage());
            throw e;
            //return null;
        }
    }

• The Exception is thrown before checking the entered OTP, so I'm guessing that .decryptWith(encryptionKey)) is the problem but I'm no expert, all I am sure of is that the same key is used for encryption & decryption, so I can't understand what's wrong, here's the error:

io.jsonwebtoken.UnsupportedJwtException: Cannot decrypt JWE payload: unable to locate key for JWE with header: {alg=dir, enc=A256GCM}
        at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:542) ~[jjwt-impl-0.13.0.jar:0.13.0]
        at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:364) ~[jjwt-impl-0.13.0.jar:0.13.0]
        at io.jsonwebtoken.impl.DefaultJwtParser.parse(DefaultJwtParser.java:94) ~[jjwt-impl-0.13.0.jar:0.13.0]
        at io.jsonwebtoken.impl.io.AbstractParser.parse(AbstractParser.java:36) ~[jjwt-impl-0.13.0.jar:0.13.0]
        at io.jsonwebtoken.impl.io.AbstractParser.parse(AbstractParser.java:29) ~[jjwt-impl-0.13.0.jar:0.13.0]
        at io.jsonwebtoken.impl.DefaultJwtParser.parseSignedClaims(DefaultJwtParser.java:827) ~[jjwt-impl-0.13.0.jar:0.13.0]
        ...

• Note that the previous methods were working fine when they were just for JWS, all I changed was the following;

1. SecretKey key = Jwts.ENC.A256GCM.key().build(); instead of SecretKey key = Jwts.SIG.HS256.key().build();
2. encryptionKey = new SecretKeySpec(Decoders.BASE64.decode(encryptKey), "AES"); instead of key = Keys.hmacShaKeyFor(Decoders.BASE64.decode(secretKey));
3. .encryptWith(encryptionKey, Jwts.ENC.A256GCM) instead of .signWith(key)
4. .decryptWith(encryptionKey) instead of .verifyWith(key)
5. .parseEncryptedClaims(token) instead of .parseSignedClaims(token)

• And yes, using 0.13.0:

<dependency>
	<groupId>io.jsonwebtoken</groupId>
	<artifactId>jjwt-api</artifactId>
	<version>0.13.0</version>
</dependency>

<dependency>
	<groupId>io.jsonwebtoken</groupId>
	<artifactId>jjwt-impl</artifactId>
	<version>0.13.0</version>
	<scope>runtime</scope>
</dependency>

<dependency>
	<groupId>io.jsonwebtoken</groupId>
	<artifactId>jjwt-jackson</artifactId>
	<version>0.13.0</version>
	<scope>runtime</scope>
</dependency>

I would really appreciate any help or clarification on what I'm doing wrong here.

[lhazlewood]

Hi there!

I'm not sure what is causing your exception to be honest. I just ran this test locally and it passed without throwing any exceptions:

    @Test
    public void testIssue1050() {
        final SecretKey generated = Jwts.ENC.A256GCM.key().build();
        String encoded = Encoders.BASE64.encode(generated.getEncoded());

        final SecretKey encryptionKey = new SecretKeySpec(Decoders.BASE64.decode(encoded), "AES");

        String subject = "testUser";
        long emailDurationMillis = 1000 * 60 * 10; // 10 minutes
        String otp = "123456";

        String jwe = Jwts.builder()
                .issuer("My App")
                .subject(subject)
                .issuedAt(new Date(System.currentTimeMillis()))
                .expiration(new Date(System.currentTimeMillis() + emailDurationMillis))
                .claim("otp", otp)
                .encryptWith(encryptionKey, Jwts.ENC.A256GCM)
                .compact();

        Claims claims = Jwts.parser()
                .decryptWith(encryptionKey)
                .requireIssuer("My App")
                .require("otp", otp)
                .build()
                .parseEncryptedClaims(jwe)
                .getPayload();
        
        assert claims.getSubject().equals(subject);
    }

The only thing I noticed when copy-pasting your code into my IDE is that it warned that it couldn't compile due to this line:

.decryptWith(encryptionKey))

since there shouldn't be a second/trailing closing parenthesis.

But I just assumed that was a typo and removed it, and then the above code worked.

The only thing I can think of is something might be off with how the Base64 string is created/exported and then read into the program. It's just a guess though. Ensure it's not Base64Url, no trailing characters have been removed, etc.

Hopefully this helps!

[Timdebo]

Hi, thank you for the quick answer, I read it a while ago but tried to find the issue before I reply here.

Turns out, my custom authentication filter was trying to validate the encrypted token using the signed token method, and when the exception was thrown, instead of handling it and letting other filters take control, I just caught it and threw it again, messing up everything.

This is quite embarrassing, sorry 🥲

[lhazlewood]

No worries! It happens to all of us. I'm glad you found the solution! 🎉

That said, just in case it is helpful for you or anyone else that may see this in the future:

JWEs alone are not suitable as authentication tokens if the token creator and the token receiver are different entities (machines, people, apps, etc) or when using public key cryptography; a JWE only guarantee that:

1. only the intended recipient can decrypt it, and
2. no-one has changed the JWE in transit without being detected.

A (public key) JWE does not prove the identity of the JWE creator or sender, so anything in the token could be fake/spoofed.

So if the token creator and receiver are different entities/parties (or using public keys), and an authentication token needs to contain sensitive or confidential information, it is best to wrap a JWE within a JWS. That is, a JWE becomes the payload of a JWS:

The 'outer' JWS is signed, and the recipient verifies the identity/authenticity of the JWS first, and once verified as known/trusted, the recipient then decrypts the 'inner' payload JWE to extract the confidential/sensitive information within.

If the token creator and the token receiver are the same, such as a web server authenticating a user via OAuth2 (or similar) for its own purposes, a JWE can be a sufficient authentication token, assuming various best practices are also used.

I hope that helps!

[Timdebo]

Thank you for the info, but I'm not sure if I got it right (this is my first time ever doing an actual project, I just learnt a bit about Spring barely two months ago):

I remember reading online about your same suggestion (wrapping JWE within JWS), which was what I planned to do, until I briefly read the JJWT documentation (which is very well explained and easy to follow!) saying that JWE by itself is not safe with any random algorithm, but must be paired with one of the authenticated encryption algorithms mentioned in the JWE section of the docs. So I thought that using one of these algorithms is enough? should I wrap it anyway?

"If the token creator and the token receiver are the same, such as a web server authenticating a user via OAuth2 (or similar)":
this is exactly my case, just a singular backend.
I first applied JWS authentication (contains the user ID as a UUID), then needed to add email verification, and since both the email and the OTP are sensitive information, I needed to encrypt them using JWE. So the auth flow is something like:

/login or /signup: if entered credentials are correct, create a JWE to verify email.
/verify: if entered code is correct, create an access token (saved in memory) & a refresh token (saved as an HttpOnly Cookie) which are both JWS. (Access token checked through a custom filter).
As well as other endpoints and logic for rotation and revocation (also handled the case of using a stolen refresh token).

Would appreciate your opinion on my humble JWT auth service if possible!

[lhazlewood]

Thank you for the info, but I'm not sure if I got it right (this is my first time ever doing an actual project, I just learnt a bit about Spring barely two months ago):

No worries! We all start somewhere, and I'm happy to help 😄.

JWE by itself is not safe with any random algorithm, but must be paired with one of the authenticated encryption algorithms mentioned in the JWE section of the docs. So I thought that using one of these algorithms is enough?

I'd probably rephrase this as (at least it makes sense in my mind as):

"An AEAD algorithm that will encrypt the JWE payload must be paired with a key management algorithm used to determine the AEAD key."

This is because a JWE payload is always encrypted/decrypted using a symmetric key AEAD algorithm, but we also want to be able to use asymmetric key algorithms (like RSASSA-PSS, Elliptic Curve, etc). So that's supported by using algorithms to encrypt/decrypt the AEAD key itself, which is then in turn used to encrypt/decrypt the payload.

This is described/shown pseudo code here: https://github.com/jwtk/jjwt#jwe-key-management-algorithms

But what does 'authentication' mean in this (AEAD) context?

The first A (Authenticated) in AEAD means that the algorithm simultaneously ensures confidentiality (it's secret) as well as data integrity. That is, the data is 'authentically' (proven) to be unmodified; it is ensured that it is authentic only in that it hasn't changed after creation.

This is a different concept from "the party (user, machine, whatever) that gave this to me is who they say they are", which is what we often think of as (user) authentication.

So AEAD is about data (raw bytes) authenticity, not user/identity authenticity - two different kinds of authentication.

"If the token creator and the token receiver are the same, such as a web server authenticating a user via OAuth2 (or similar)": this is exactly my case, just a singular backend. I first applied JWS authentication (contains the user ID as a UUID), then needed to add email verification, and since both the email and the OTP are sensitive information, I needed to encrypt them using JWE. So the auth flow is something like:

/login or /signup: if entered credentials are correct, create a JWE to verify email. /verify: if entered code is correct, create an access token (saved in memory) & a refresh token (saved as an HttpOnly Cookie) which are both JWS. (Access token checked through a custom filter). As well as other endpoints and logic for rotation and revocation (also handled the case of using a stolen refresh token).

This scenario is actually an excellent example illustrating data authenticity vs identity authenticity:

A JWE in a URL for email verification (produced by the server, consumed by the same server) can be verified that it is 'authentically unmodified'.

But it can't be used to prove that the person accessing that URL is the actual user it was created for. For example, if the original recipient forwards the email to someone else, that 3rd party could click the link to verify the email.

The verifying of other data (CSRF tokens, HTTPS-only cookies, OTP, browser fingerprint, IP address, etc) against the JWE is what ensures that the user executing the request has a higher degree of identity authenticity.

This is why clicking an email verification link will log-out / force a new log-in in more secure systems: even if the intended recipient forwarded the email to a 3rd party, and that 3rd party clicked it, the email can still be recorded as valid (because it couldn't have been forwarded otherwise). But a 3rd party wouldn't be authenticated or 'logged in' just by clicking the link because they'd still need to prove their identify first.

should I wrap it anyway?

I don't think you need to in your case, but since I don't know as much about your system, it's probably better to state:

JWE-within-JWS is preferred when data confidentiality is required and:

1. The creator and recipient are separate parties, OR
2. A public key used during JWE encryption is publicly accessible or may easily become publicly accessible (e.g. by employees or in configuration files, or committing to GitHub, etc).

It's also very important in cryptographic contexts that the same key that is used for signing is not used for encryption and vice versa.

So if you do use JWE-within-JWS, ensure you have one key that creates the JWE and a totally separate key that signs the JWS, and never use either for anything else.

[Timdebo]

Looks like I need to dive much deeper to grasp the full picture, but you helped me pinpoint the difference between data authenticity and identity authenticity, thank you very very much for that and for taking the time to help me out.

Hope I can contribute back once I get the hang of it. 🍀🍀