You can accomplish what you want using multiple distinct Apigee policies.
In the description, you didn't say that you want to validate the inbound JWT, but even if you didn't state it, that is probably what you want to do. If you don't validate the JWT, then the API proxy will accept any JWT, and in fact any client could send in anything and assert "this is a JWT", and your proxy would allow it. That would be bad. So it seems safe to assume you will want your API proxy to validate the JWT. I'll assume we are discussing a signed JWT for the purposes of this answer.
Validating means
- verifying that the signature has been created by a trusted party. (The public key is trusted)
- verifying that the JWT is not expired, and is not being presented before the not-before time
- verifying any additional claims in the JWT - like audience, or issuer, etc
You can do all of that stuff with the VerifyJWT policy. It might look like this:
<VerifyJWT name='VJWT-1'>
<Algorithm>RS256</Algorithm>
<!-- omit the Source element if the JWT is in the Authorization header -->
<Source>inbound.jwt</Source>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
<PublicKey>
<JWKS uri='https://my-jwks.endpoint.com/jwks.json'/>
</PublicKey>
<Issuer>something.example.com</Issuer>
<Audience>urn://example.com/my-desired-audience</Audience>
</VerifyJWT>
Next you probably want to validate that the JWT is good for this particular API. In Apigee, APIs are exposed as Products, and in order to check that an inbound request should be allowed, You can use a credential verification policy in Apigee to check that the presented credentials are good for an API Product which includes the given API proxy (or the given API verb + path pair). To do this in Apigee, you can use either the OAuthV2 policy configured with the VerifyAccessToken Operation, or the VerifyAPIKey policy. Use the former when the app credentials are in the form of an opaque access token. Use the latter when the app credentials are in the form of an API Key.
In the case of a signed JWT, typically one of the claims carries the Api key. This might be a claim named client_id, or something like that. In that case, you can use VerifyAPIKey passing the variable name that contains that decoded claim.
<VerifyAPIKey name='VAPIKEY-1'>
<!-- check that the client id embedded in the JWT is good for this API -->
<APIKey ref='jwt.VJWT-1.decoded.claim.client_id'/>
</VerifyAPIKey>
OK, with those two policies we have
- verified that the JWT can be trusted and has valid dates
- verified that the client ID embedded in the JWT is good for THIS api product
What remains now is to enforce the rate limit.
You said you want to enforce a quota (rate limit), using a different quota bucket for each... ? each what? Your original question was "for each JWT" but I think that is probably not the right way to do it. A client might obtain a new JWT with each request, and each new token gets a new bucket, a new quota count allocation. That's probably not what you want.
Instead, you can enforce a quota on the client id, which will remain constant even if the client obtains new JWT periodically. Supposing your quota information is attached to the API Product, you can enforce the quota with this kind of Quota policy.
<Quota name="Quota-1">
<Identifier ref="verifyapikey.VAPIKEY-1.client_id"/>
<Interval ref="verifyapikey.VAPIKEY-1.apiproduct.developer.quota.interval">1</Interval>
<TimeUnit ref="verifyapikey.VAPIKEY-1.apiproduct.developer.quota.timeunit">hour</TimeUnit>
<Allow count="5"
countRef="verifyapikey.VAPIKEY-1.apiproduct.developer.quota.limit"/>
<Distributed>true</Distributed>
<Synchronous>false</Synchronous>
</Quota>
If you want a "hard coded" quota settings, then you can use this simpler policy configuration instead:
<Quota name="Quota-1">
<Identifier ref="verifyapikey.VAPIKEY-1.client_id"/>
<Interval>1</Interval>
<TimeUnit>hour</TimeUnit>
<Allow count="5"/>
<Distributed>true</Distributed>
<Synchronous>false</Synchronous>
</Quota>
In any case, you will need three policies. The flow would be something like this:
<!-- verify the JWT -->
<Step>
<Name>VJWT-1</Name>
</Step>
<!-- check that the client id embedded in the JWT is good for this API -->
<Step>
<Name>VAPIKEY-1</Name>
</Step>
<!-- enforce a quota based on the client id -->
<Step>
<Name>Quota-1</Name>
</Step>
LinkedIn
Twitter
