Decoding a Microsoft OAuth token: use of "jku" field specified, but the field is empty about jwx HOT 8 CLOSED

From the error message, and the header information that you have provided, I'm guessing most likely means exactly what the error says: For whatever reason, you (trafficcontrol) requested jwx to decode it using JKU, but the JWS did not contain a JKU field, suggesting that the code that lead to the execution of WithVerifyAuto is wrong?

from jwx.

Was the old code expecting it to say: "Oh, this JWS doesn't have JKU, so I'm just going to let it go"? Otherwise, I think jwx is doing the right thing by rejecting JWS without a JKU.

from jwx.

Was the old code expecting it to say: "Oh, this JWS doesn't have JKU, so I'm just going to let it go"? Otherwise, I think jwx is doing the right thing by rejecting JWS without a JKU.

It looks like before apache/trafficcontrol@aa990dfc80 (using dgrijalva/jwt-go), the old code would have panicked if there was not a JKU:

		decodedToken, err := jwt.Parse(encodedToken, func(unverifiedToken *jwt.Token) (interface{}, error) {
			publicKeyUrl := unverifiedToken.Header["jku"].(string)
			publicKeyId := unverifiedToken.Header["kid"].(string)
			/*...*/

So maybe Traffic Control never worked with Microsoft Oauth? It looks like we'll need to support decoding it without a JKU.

from jwx.

So maybe Traffic Control never worked with Microsoft Oauth?

I really don't know much about MS OAuth, but I have had people report to me strange, i.e. MS-specific, behavior from time to time in the workflow, so it wouldn't surprise me... :)

It looks like we'll need to support decoding it without a JKU.

In that case I think the current workaround would be

if err := jwx.Parse( withJKU) ;  err != nil {
   if err := jwx.Parse( withoutJKU ); err != nil {
      return fmt.Errorf(`we got a problem: %w`, err)
   }
}

I suppose jwx could incorporate a new feature, some sort of "fallback to using keys if JKU is not present" as well, but I have slight concerns in terms of security (note: haven't thought it through, so I may be wrong)

from jwx.

I suppose jwx could incorporate a new feature, some sort of "fallback to using keys if JKU is not present" as well

If I hard-code the JKU as https://login.microsoftonline.com/<app ID>/discovery/v2.0/keys (which is in the same format as https://login.microsoftonline.com/common/discovery/v2.0/keys) at

but I have slight concerns in terms of security (note: haven't thought it through, so I may be wrong)

Do you have those same concerns about providing a fallback JKU, rather than specifying fallback keys directly?

from jwx.

I think my beef is in that the jku mechanism implicitly fetches remote resources. Adding a way for users to specify that URL is always scary to me, because I firmly believe that users (not you per se, but other random users) will go out of their way to harm themselves.

I have a feeling in your usecase it's far safer to use jwk.CachedSet. e.g.

1. determine if this is a MS token
2. if yes, use a jwk.CacheeSet w/o using JKU
3. if no, use JKU

(I didn't check with you if it's possible to determine if the toke is from MS, but I figured it wouldn't make sense to specify a fallback URL unless you could determine if where the token came from, so....)

that's my initial assessment. let me know if I'm missing something.

from jwx.

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

from jwx.

This issue was closed because it has been stalled for 7 days with no activity. This does not mean your issue is rejected, but rather it is done to hide it from the view of the maintains for the time being. Feel free to reopen if you have new comments

from jwx.