Hi,
Can you elaborate on what you mean by this:
JWS signature is valid but claim is invalid.
The validity of a signature on a JWT can be objectively assessed. It's either valid or it is not. At that point, the validating party (in this case, maybe your Apigee API proxy) can trust that the claims are bona-fide, they can be relied upon. And the validating party can then make a determination whether the values of the bona-fide claims are satisfactory. That determination will vary depending on the scenario. For example the validating party might insist that the "iss" claim in the token is present, and has a particular value. If the "iss" doesn't have the expected value, then ... the validating party can reject the token for the purposes of authorization. The token is valid, but the claim is not suitable or satisfactory. And of course you could apply similar logic for any claim in the token, either a registered claim (sub, aud, etc) or a custom claim.
Suppose client sending same JWT token with invalid claim for thrice within five seconds. Then black out the customer for 15 seconds .
It depends on what you mean by "invalid claim".
I'm not clear on the problem you're solving.
I mean I understand "replay" and "Three times in five seconds"... but... really what are we trying to protect against here? You might think to use a Quota policy for rate limiting. But Quota does not allow an arbitrary reset period (like 15 seconds) after reaching the quota limit.
You could use the Apigee cache for the purpose of disabling the service for 15 seconds. But that's not necessarily a distributed cache, which means in a multi-region Apigee instance, the cache won't be distributed everywhere all at once, and there would be a way for users to evade the "deny the customer for 15 seconds" action.
In either case, you would need a unique identifier for the JWT to use as the "key" for either the cache or the quota policy. You could use the JTI for that purpose, if there is one. Or, you could use a sha256 of the JWT itself - that will be unique for each distinct JWT. You can produce a sha256 with AssignMessage/AssignVariable - use a static function in the "Message Template". Consult the documentation for more info on that.
But again, I am not clear. Why allow THREE invalid requests and only deny AFTER that? Why not keep it simple and deny service for 15 seconds after the FIRST request with an invalid token?
LinkedIn
Twitter
