There are some changes and enhancements coming in the JWT policies in Apigee Edge.
The Highlights:
And here are some details:
There is one case in which we have tightened the security around JWT (and JWS) - involving HS* algorithms. Previously the policies allowed weak keys when signing. Now, the keys must have the minimum size - 32 bytes for HS256, 48 for HS384 and 64 for HS512. With the upgrade, you will now get an error at runtime if you try to sign or verify with HS* using a key of insufficient length. To avoid this, use a stronger key.
Not included in this update is any support for JWE. Encrypted JSON Web Tokens are not yet natively supported by Apigee Edge builtin policies.
Check the release notes when they become available for full details.
Is there any way to manage the Algorithm type dynamically in GenerateJWT Apigee policy ?
I tried
<Algorithm>{my_alg}</Algorithm>
<Algorithm>my_alg</Algorithm>
<Algorithm ref="my_alg"/>
<Algorithm>
<Value ref="my_alg"/>
</Algorithm>
Thanks
No, there is no way to do that.
And that is by design. The algorithm family is fixed. This is to prevent a well-known attack vector on JWT, in which the sender asserts the algorithm and asks that the receiver verify the signature using the asserted algorithm. This is bad practice, so we decided to "discourage it" by not providing the possibility to specify the algorithm by reference.
what is your real use-case?
I develop an oauth proxy which delivers JWT token or opaque token according to a custom attribut set in the each product. This proxy is common for products of my organization?
For opaque token I need and oauthV2 policy
For JWT I need 2 policies :
- one for HS_* algorithm
- one for others
If the <Algorithm> is hardcoded and if I want to be able to manage all algorithms I need to implement... 12 policies 😞
I understand the situation you're describing. Apigee JWT policies do not support dynamic specification of the JWT algorithm; this is done to prevent a well-known security problem with the *use* of JWT. It is not a security issue within JWT; but acceptance of a dynamically-specified (client specified) algorithm is a common pitfall in JWT usage . The design of the JWT policies was intended to avoid that class of pitfall.
This is generally a good tradeoff, even if it doesn't satisfy your specific desires. In my experience, organizations do not support all of the various signature algorithms stipulated in the JWA specification (IETF RFC 7518), all of which are supported in the Apigee JWT policies. Instead, the organization evaluates the algorithms and the key management requirements supporting each of them, and chooses one algorithm as preferred.
I regret that your chosen design would require 12 policies; even so, I think the design decision taken with the Apigee JWT policies is still the correct one. In the Apigee JWT policies, there is no support for specifying the accepted, allowable algorithms at runtime via a variable, and that will not change.
If the <Algorithm> is hardcoded and if I want to be able to manage all algorithms I need to implement... 12 policies :-(
Yes, and I think this is a case of YAGNI. If you would like to avoid the 12 policies, then I suggest that you restrict the set of Algorithms you support in your APIs.
Thank you Dino for this advice
A last question: I work on 4.19.01.00 on premice version. It seems that this version support only HS256 and RS256 right ?
Thanks a lot
Yves
That is correct. The expanded set of algorithms (ECDSA and PSS) will be available in 19.06, I believe.