How to verify JWT claims by checking only existence and types

[Lola2019]

Hey, 

When learning and searching for THE best way to verify a JWT , I have got only one question that wasnt answered for. I would like to get a response for it please to insure my development idea.

I have JWT that has Claims in it (like da), some are according the registered claims mentioned in RFC7519 . but the JWT also has Claims that are created according and for my needs.  for example see below from GenerateJWT:

....

<AdditionalClaims>
<Claim name="newClaim1" type="string" ref="apigee.developer.somedtl"/>
<Claim name="newClaim2" ref="apiproxy.somedtl2"/>
<!-- legacy -->
<Claim name="newClaim3" ref="apigee.developer.somedtl3"/>
<!-- from jwt assertion -->
<Claim name="newClaim" ref="accesstoken.newClaim"/>

....

when I get to AccessToken API I want to verify the JWT Ive got in the request.

BUT, my verification for the JWT needs to be also with/for the claims Ive had  registered when the JWT was created. not a verification for existence of those claims and their implicit values , but a verification that consists a validation that my registered claims that I was created - exists AND the values that sent to it is are as the declared type of.

NOW  before sending me to schema validation , js and more solutions I would like to know why shouldn't I use a DecodeJWT policy before the JWTVerify policy ? Isnt it a batter solution to my need? even though the JWT is opened twice and as best practice is it once we need to use one of those policy. Isnt my case declared above is the only one case to use those both ?

thank you in advanced ! waiting to hear from you your opinion please.

@dchiesa1 

[dchiesa1 · Accepted solution]

---

BUT, my verification for the JWT needs to be also with/for the claims Ive had registered when the JWT was created. not a verification for existence of those claims and their implicit values , but a verification that consists a validation that my registered claims that I was created - exists AND the values that sent to it is are as the declared type of.

---

I am not quite clear on your requirements. I appreciate your effort to explain what you want, but despite your efforts some things are not clear to me. I will guess that what you want is to verify the PRESENCE of specific claims within the JWT, and the data type of those claims, without verifying the specific VALUE of those claims.

You can do that with DecodeJWT and then a subsequent step like a JavaScript policy, as I think you were suggesting. But the VerifyJWT will also decode the JWT implicitly and it will set the same variables that the DecodeJWT policy sets. You can think of VerifyJWT as a superset of DecodeJWT. So your logic sequence might be:
- VerifyJWT
- JavaScript

In the JavaScript you would just retrieve the context variable corresponding to the claim, and test it’s value. Or if there are multiple claims, do those steps in a loop.

You typically don’t ever need to use DecodeJWT, with one exception: if you need to examine the claims within the JWT to determine how to validate/verify the JWT. If, for example, your proxy can receive JWT from different issuers and needs to use different VerifyJWT configuration based on the iss claim, that would be a reason to use DecodeJWT.

There is an outstanding proposal to enhance the VerifyJWT policy to verify the presence of a claim, by name, without checking a specific value. That enhancement has not yet been implemented.

EDIT - I misspoke. That feature has been implemented in Apigee X and hybrid. There is a new configuration element in the VerifyJWT policy - RequiredClaims. Usage is like this:

<VerifyJWT name='VerifyJWT-Signed-RSA'>
  <Algorithm>RS256</Algorithm>
  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <PublicKey> ...  </PublicKey>
  <!-- this configuration element is new -->
  <RequiredClaims>sub, iss, exp, iat, non-registered-claim</RequiredClaims>
  ...

You can specify a comma-separated list of claim names. When this element is present the policy verifies that the JWT contains those claims, but does not verify their content or data type.

[Lola2019]

Ok ok ok! So excited 😆 I’m serious.

First, you actually did understand my question 😉

Secondly, THANK YOU! for your answer to me , I was happy  to read your reply - my friends got to hear my enthusiasm 

My proxy purpose is to give an access token according to a given jwt  assertion and client credentials.

As a concept, the whole implementation details  is  quite clear and  irrelevant for my specific question. 

I did try to explain more than I needed. So sorry for that.

All that I want is to get to know the new element configuration - AWESOME! 

but,  I am using Apigee Edge Private Cloud , therefor I was asking for the use of DecodeJWT and VerifyJWT policies one after the other and only within that proxy to give the accessToken accordingly.

As you wrote the exception (below), Is not that solution is a batter than writing a  JavaScript

"with one exception: if you need to examine the claims within the JWT to determine how to validate/verify the JWT. If, for example, your proxy can receive JWT from different issuers and needs to use different VerifyJWT configuration based on the iss claim, that would be a reason to use DecodeJWT."

@dchiesa1