Extracting ISS claim before decoding token to access JWKs

[alonbl]

Hello,

If I support multiple ISS, I imagine the following sequence:

• Decode the jwt claims (insecure).
• Extract the iss claim from the jwt decode.
• Verify that this iss claim value is one of the allowed one (whitelist)
• Download $iss/.well-known/openid-configuration
• Extract the jwks_uri from body
• Download $jwks_uri
• Decode the jwt and verify signature based on the jwks (secure)
• Verify claims

I believe the authlib library is missing the ability to extract claims before signature validation.

Is there different sequence to accomplish the requirements?
I can pre-download jwks of every iss and verify the jwt against each, but this is a waste of resources (performing unnecessary RSA).

Thanks,

[ironhacker]

I'm also wondering how to do this. In fastapi_azure_auth, I can pass a an "iss_callable" to the authorization scheme. I use this to whitelist tenants in a multi tenant setup.

[lepture]

@alonbl @ironhacker

The key can be a callable function.

def load_key(header, payload):
    return get_iss_key(payload['iss'])

[alonbl]

Hello @lepture,

Thank you for your suggestion, I believe this is not sufficient, I will try to explain why...

The secure process as far as I understand should be:

1. Acquire the iss claim (insecurely)
2. Fetch the key based on the value obtained by (1)
3. Verify the jwt signature.
4. Aquire the iss claim again (securely) and compare it to (1), so we know we have used the correct value to obtain the key.

Having this done in the load_key() does not allow me to perform step (4) as atomic, unless we add some context reference to the operation.

I also could not find how to do so in the new joserfc.jwk.GuestProtocol, it does not provide access to claims, maybe I am missing something... It will also be nice if the guess can return joserfc.jwk.KeySet and not specific key and let the class resolve the key to avoid logic duplication.

I believe that the simplest method would be something like:

insecure_token = joserfc.jwt.decode(token, validate=False)
insecure_iss=insecure_token.claims["iss"]
# Load KeySet
token = joserfc.jwt.decode(token, key=keyset)
token.claims["iss"] != insecure_iss:
    raise Exception("xxx")

What do you think?

[lepture]

@alonbl actually, with joserfc you can do it step by step. I'll update the documentation at https://jose.authlib.org/en/dev/recipes/azure/

[alonbl]

Hello @lepture ,

Thank you for your example:

    def load_key(obj: CompactSignature):
        claims = json.loads(obj.payload)
        issuer_url = claims['iss']

       <snip>

        # pick the key with kid
        key_set = KeySet.import_key_set(resp.json())
        key = key_set.get_by_kid(obj.headers()['kid'])
        return key

    # pass load_key as a callable key to `jwt.decode` method
    jwt.decode(token_string, load_key)

I am still missing the last step I outlined:

Acquire the iss claim again (securely) and compare it to (1), so we know we have used the correct value to obtain the key.

I also would like to suggest again to support KeySet. The jwt.decode() already supports KeySet callback should be only delegation, the logic of acquiring a key out of a KeySet by any mean (may it be kid or other) is already implemented in the library and should not be duplicated, this will have consistent behavior with or without using the callback.

Per example:

-        key_set = KeySet.import_key_set(resp.json())
-        key = key_set.get_by_kid(obj.headers()['kid'])
-        return key
+        return KeySet.import_key_set(resp.json())

The following codes should behave exactly the same using the library logic:

jwt.decode(token, keyset)
jwt.decode(token, callback)  # callback return keyset in parity with previous

If the callback wishes to apply its own logic it may return a specific key, however, default behavior should avoid duplication of library implementation.

Thanks!

[lepture]

@alonbl good suggestion. The callable key can return str, bytes, Key, KeySet now authlib/joserfc@43be0a2

[alonbl]

Thanks @lepture : we should simplify this even more.

Looking the following hunk:

    def load_key(obj: CompactSignature):
        claims = json.loads(obj.payload)
        issuer_url = claims['iss']

Parsing the claim in a safe way is already a feature of the library, there is no reason why the callback should duplicate the logic and parse the payload by itself.

Also, we should keep this iss claim to later compare it to the iss after signature validation, so we make sure the insecure parser extracted the correct field. If we do this in the callback we should have somekind of context to be able to expose variables out.

[lepture]

The key is used in many places. The protocol for the callable key only requires headers and set_header method. There are JWS and JWE, and there are compact and JSON serialization. The callable key doesn't know it is a JWT.

[alonbl]

Hello @lepture,

Thank you so much for the discussion.

I would like to address the following statement:

The callable key doesn't know it is a JWT.

I argue that a callback to jwt is aware of jwt, it should be able to handle jwt. Lower level library classes may be unaware.

The jwt.decode() may wrap the callback to lower level, even without modifying the signature and by adding context something like:

    import functools

    def jwt_guess_wrapper(original, arg):
        obj.context["insecure_claims"] = json.loads(obj.payload)
        original(obj)

    def jwt_decode(key):
        if callable(key):
            key = functools.partial(jwt_guess_wrapper, key)
        ...

    def mycallback(arg):
        print(arg.context["insecure_claims"])

    token = test1(mycallback)
    print(token.context["insecure_claims"])

This actually also solves the issue of validate the insecure parsing with secure parsing as the context is available after the decode.

What do you think?

[alonbl]

BTW:

As far as I understand the callback should return KeyBase as the following, bug KeyBase is not exposed, can you please expose it?

def load_key(obj: CompactSignature) -> KeyBase:
    ...

[lepture]

@alonbl 0.9.0 is released. Documentation on this case: https://jose.authlib.org/en/dev/recipes/azure/