JWK Secret Environment

[jfslin]

Hello, I am trying to setup a Quarkus app with Supabase Auth as a backend. Supabase Auth provides a HS256 JWT for authentication as well as a secret key string. Using #25632 and https://quarkus.io/guides/security-jwt, I was able to setup a secretkey.jwk file and got the the security @Context working.

Now I have a plaintext .jwk file that looks like this

{
  "kty": "oct",
  "kid": "kidstring",
  "k": "kbase64string",
  "alg": "HS256"
}

but figured I shouldn't save this file into my Github repo publicly since HS256 uses symmetric keys. Attempts to use an environment variable didn't work:

{
  "kty": "oct",
  "kid": ${AUTH_KID},
  "k": ${AUTH_K_BASE64}",
  "alg": "HS256"
}

Is there perhaps a way to save my .jwk file into my application.properties where i can use my .env variables? or is there any other best practice to approach this? Thank you.

[sberyozkin]

@jfslin Hi, can you please point to the Base64URL encoded string representing this JWK ? I don't recall right now if it will work for this case, but smallrye-jwt will attempt decode strings and treat them as JWKs as well.

The only problem you'd have to use mp.jwt.verify.publickey={encodedjwk} which is a bit confusing since it is not a public key.
But if that works then I can add a smallrye-jwt specific property for inlining keys as well

[jfslin]

@sberyozkin Thank you for the response. Sorry, I don't quite follow.

My original .jwk that uses the string version of the JWT secret looks something like this (changed kid and k for this example):

{
  "kty": "oct",
  "kid": "Sb6ml8Bc7sTDQw/",
  "k": "p13PfDdC3jmJPpM0QT5dz/zpttREbIzRudNz34IlHDeKkW/Kf2dThbmRZQXPSr/x7XSpo7acJcqnganaQz7RA1g==,
  "alg": "HS256"
}

Do you mean to feed the contents of this file and convert it to Base64 using something like https://base64.guru/converter/encode/text? So something like:

ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAicDEzUGZEZEMzam1KUHBNMFFUNWR6L3pwdHRSRWJJelJ1ZE56MzRJbEhEZUtrVy9LZjJkVGhibVJaUVhQU3IveDdYU3BvN2FjSmNxbmdhbmFRejdSQTFnPT0sDQogICJhbGciOiAiSFMyNTYiDQp9

As a side note, when I use the original .jwk, I get

2024-08-14 16:40:38,047 DEBUG [io.qua.sma.jwt.run.aut.MpJwtValidator] (vert.x-eventloop-thread-1) Authentication failed: io.smallrye.jwt.auth.principal.ParseException: SRJWT07000: Failed to verify a token
        at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parseClaims(DefaultJWTTokenParser.java:178)
        at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:60)
    ...
Caused by: org.jose4j.jwt.consumer.InvalidJwtSignatureException: JWT rejected due to invalid signature. Additional details: [[9] Invalid JWS Signature: JsonWebSignature{"alg":"HS256","kid":"Sb6ml8Bc7sTDQw/","typ":"JWT"}->eyJhbGciOiJIUzI1NiIsImtpZCI6IlNiNm1sOEJjN3NURFF3LyIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2Jxbmx2a3JtLnN1cGFiYXNlLmNvL2F1dGgvdjEiLCJzdWIiOiJiNGE3NGnvv73vv71I77-9eu-_vRMjIu-_vUMjVhLTk1NGUu-_vSNT77-9QzNDZkZjAxPvv70i77-9JhdWQiPvv70mF1dG77-9Vu-_vUbvv702F0ZWQiLvv70mV--_vQIj77-9E3MjM2NzE1Pvv70y77-9Ju-_vRdCI--_vW8bI--_vScGFzc3du-_vSZCIu-_vSdG77-977-9VzdGFu-_vQIj77-9E3MjM2Njc--_ve-_vTfvv73vv73vv70nNlc3Nu-_ve-_ve-_ve-_ve-_vUIj77-9I--_vXMz77-9Y--_vWNy77-9U--_vRZC77-9Q1M2EtOT77-977-9Mu-_vSZDBmYzZlPvv70T77-9RjIi77-9Ju-_vTXvv70W77-977-977-977-977-977-9VzIj77-9Zhbvv702V--_vQ.Ot6KpgNztZH4WiotbJ54T_sspGuCaOpzBGCnXdYImG0]
        at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:224)
        at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:410)
        at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parseClaims(DefaultJWTTokenParser.java:157)

I had to convert the k string to base64 using https://base64.guru/converter/encode/text for it to work. That is, my secretKey.jwk contains:

{
  "kty": "oct",
  "kid": "Sb6ml8Bc7sTDQw/",
  "k": "cDEzUGZEZEMzam1KUHBNMFFUNWR6L3pwdHRSRWJJelJ1ZE56MzRJbEhEZUtrVy9LZjJkVGhibVJaUVhQU3IveDdYU3BvN2FjSmNxbmdhbmFRejdSQTFnPT0=",
  "alg": "HS256"
}

So it doesn't seem like smallrye-jwt is checking the k string and trying to convert it from string vs Base64. The above jwk encodes base64 into

ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAiY0RFelVHWkVaRU16YW0xS1VIQk5NRkZVTldSNkwzcHdkSFJTUldKSmVsSjFaRTU2TXpSSmJFaEVaVXRyVnk5TFpqSmtWR2hpYlZKYVVWaFFVM0l2ZURkWVUzQnZOMkZqU21OeGJtZGhibUZSZWpkU1FURm5QVDA9IiwNCiAgImFsZyI6ICJIUzI1NiINCn0=

If it matters, my application.properties currently have these :

smallrye.jwt.verify.key.location = secretKey.jwk
smallrye.jwt.verify.algorithm = HS256

And on the latest smallrye-jwt version, ie 4.5.3

I am okay with using mp.jwt.verify.publickey={encodedjwk} for my usage right now, but wouldn't want to cause confusion for other uses. I guess this is mainly a problem for my case because Supabase is using symmetric keys? Do most people just publish their jwk files because it only contains public key?

Just to be clear, you are suggesting that I currently use Base64 version of my second jwk file for now, that is:

mp.jwt.verify.publickey=ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAiY0RFelVHWkVaRU16YW0xS1VIQk5NRkZVTldSNkwzcHdkSFJTUldKSmVsSjFaRTU2TXpSSmJFaEVaVXRyVnk5TFpqSmtWR2hpYlZKYVVWaFFVM0l2ZURkWVUzQnZOMkZqU21OeGJtZGhibUZSZWpkU1FURm5QVDA9IiwNCiAgImFsZyI6ICJIUzI1NiINCn0=
mp.jwt.verify.algorithm=HS256

instead of my existing smallrye.jwt.verify properties, and eventually this will become

smallrye.jwt.verify.key.inlinekey=ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAiY0RFelVHWkVaRU16YW0xS1VIQk5NRkZVTldSNkwzcHdkSFJTUldKSmVsSjFaRTU2TXpSSmJFaEVaVXRyVnk5TFpqSmtWR2hpYlZKYVVWaFFVM0l2ZURkWVUzQnZOMkZqU21OeGJtZGhibUZSZWpkU1FURm5QVDA9IiwNCiAgImFsZyI6ICJIUzI1NiINCn0=
smallrye.jwt.verify.algorithm=HS256

to not cause confusion between public keys and inline keys?

Thank you.

[sberyozkin]

@jfslin The fact you had to double encode k suggests the original format is incorrect, it is processed directly by jose4j.

Right, the last example is what I meant, only make sure it is base64url encoded value, and then you can use env vars to replace ${encodedkey}

[sberyozkin]

@jfslin I'll have a look, in general, the key content can be Base64URL encoded, and there are probably some MP JWT tck tests around, but I'll see what happens, can you open an issue in the smalltye jwt project please ?

[jfslin]

Thank you. I've created an issue outling the tests I've done here: smallrye/smallrye-jwt#817

I was also look for MP JWT TCK tests and came across this: https://github.com/eclipse/microprofile-jwt-auth/tree/main/tck. It seems like the current test case coverage is for RS256 and EC256 type methods, and not for HS256 symmetric key cases.

[sberyozkin]

@jfslin thanks, I've already committed tests using a JWK produced by jose4j, and as I said, I have had both base64url encoded content and raw content used.
How did you create your JWK, what was the original secret key format you got from your provider ?

FYI, symmetric signature algorithms will unlikely be ever supported at the spec level, we only did it in smallrye-jwt

[jfslin]

Sorry, I had understood your comment as "look into the existing MP JWT TCK tests for some example setups", hence those comments.

I crafted the JWK by hand based on trial and error and your tips to this issue: #25632

The secret key k is provided by Supabase Auth (https://supabase.com/docs/guides/auth/jwts - "This JWT is signed by a jwt_secret specific to the developer's Supabase token (you can find this secret alongside this encoded "anon key" on your Dashboard under Settings > API page) and is required to get past the Supabase API gateway and access the developer's project."). They don't provide the whole JWK, only the k value as a plain string.

It does seem like there is some JWK support coming in: supabase/auth#1674, but polling /.well-known/jwks.json for my Supabase endpoint gives me an empty JSON. I haven't filed a ticket on that side yet to see if they can expose the whole JWK to use yet though.

Thank you for supporting the symmetric algorithm. I recognize that we're likely in the niche.

[sberyozkin]

@jfslin thanks, right, I saw the original k was base64 encoded with padding, so it was not correct. But in any case, good you have found the correct form. In general it is a base 64 url encoder without padding which must encode k.

Let's finalize at the smallrye jwt level, please confirm there you can have it working with the latest source

[sberyozkin]

@jfslin I've added a couple of tests, inlining the raw JWK content and base64url encoding it works, watch smallrye/smallrye-jwt#814

[jfslin]

Marking this discussion as complete. HS256 BASE64URL support for JWK added in smallrye/smallrye-jwt#814. Additional discussions at smallrye/smallrye-jwt#817. Thank you again.

[jfslin]

For future users, if you are using HS256 and want to use inline (ie Supabase Auth):

Generate your JWK. Supabase does not generate it for you so you need to craft one by hand. If your k is in string (ie as is the case in Supabase), make sure it's converted to BASE64URL with a tool like https://base64.guru/converter/encode/text. You will end up with something like this

{
  "kty": "oct",
  "kid": "Sb6ml8Bc7sTDQw/",
  "k": "cDEzUGZEZEMzam1KUHBNMFFUNWR6L3pwdHRSRWJJelJ1ZE56MzRJbEhEZUtrVy9LZjJkVGhibVJaUVhQU3IveDdYU3BvN2FjSmNxbmdhbmFRejdSQTFnPT0"
  "alg": "HS256"
}

then take this entire content and reparse it in BASE64URL again, leaving you with

ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAiY0RFelVHWkVaRU16YW0xS1VIQk5NRkZVTldSNkwzcHdkSFJTUldKSmVsSjFaRTU2TXpSSmJFaEVaVXRyVnk5TFpqSmtWR2hpYlZKYVVWaFFVM0l2ZURkWVUzQnZOMkZqU21OeGJtZGhibUZSZWpkU1FURm5QVDA9IiwNCiAgImFsZyI6ICJIUzI1NiINCn0=

Then the following will work

smallrye.jwt.verify.secretkey=ew0KICAia3R5IjogIm9jdCIsDQogICJraWQiOiAiU2I2bWw4QmM3c1REUXcvIiwNCiAgImsiOiAiY0RFelVHWkVaRU16YW0xS1VIQk5NRkZVTldSNkwzcHdkSFJTUldKSmVsSjFaRTU2TXpSSmJFaEVaVXRyVnk5TFpqSmtWR2hpYlZKYVVWaFFVM0l2ZURkWVUzQnZOMkZqU21OeGJtZGhibUZSZWpkU1FURm5QVDA9IiwNCiAgImFsZyI6ICJIUzI1NiINCn0=
smallrye.jwt.verify.algorithm=HS256

[sberyozkin]

Thanks @jfslin, FYI, I had to fix a couple of typos in your last example...

I'll add an example here in Quarkus docs as well, one we update it to 4.5.4

[sberyozkin]

@jfslin FYI, #42629, note the release version will be 4.6.0 as there will be at least 2 other important issues fixed.

As it happens, your tests did find the issue, thanks for that, which you worked around with setting a public key algorithm, but it will be fixed shortly in smallrye-jwt main

[jfslin]

Sounds good. Watching #42629. Thank you again.