Can I Templatize the Issuer in VerifyJWT policy? And which claims should I verify?

Hi,

I have a requirement to templatize the <Issuer> in JWTValidation policy

Like

<VerifyJWT async="false" continueOnError="false" enabled="true" name="Ver-JWT">
  <DisplayName>Ver-WT</DisplayName>
  <Algorithm>XX555</Algorithm>
  <Source>source variable</Source>
  <PublicKey> <JWKS ref="key.content"/> </PublicKey>
  <Issuer>https://IPV4Address/url1/url2/(templatizedvariable)</Issuer>
</VerifyJWT>

The challenge is only in JWTValidation policy Issuer cannot be templattized (Is it true?), but when I use the Service callout policy there the templattized logic works perfect with same variable.

variable "templatizedvariable" value is getting populated (when I enable the trace for JWTValidation policy) but when i hardcode "templatizedvariable" it works fine else gives error when I put (templatizedvariable) in <Issuer> of JWTValidation Policy

Q 2. Whats the best practice for JWT Validation or how depth our validation of JWT need to be ?:

Do the public key validation and Algorithm validation is sufficient or Issuance and other customer parameter of JWT Token need to be validated by JWTValidation Policy ?

1 2 184
2 REPLIES 2

sidd-harth
Participant V

Did you try the ref tag?

Use an Assign Message policy to create a new flowVariable with the entire URL with Templatizedvariable.

In JWT use,

<Issuer ref='flowVariable'/>

Befor JWT use an AssignMessage Policy,

 <AssignVariable>
        <Name>templatizedvariable</Name>
        <Value>any-value</Value>
        <Ref/>
    </AssignVariable>
    <AssignVariable>
        <Name>flowVariable</Name>
        <Value/>
        <Template>https://IPV4Address/url1/url2/{templatizedvariable}</Template>
 </AssignVariable>

The Template tag might not work on older on-prem orgs.

in [VerifyJWT] policy Issuer cannot be templattized (Is it true?),

Yes, true. According to the documentation for the VerifyJWT policy, you can specify a fixed value or a variable reference for the Issuer. As Siddharth pointed out, you can use AssignMessage to populate a new variable with a Template.

but when I use the Service callout policy there the templattized logic works perfect with same variable.

Different configuration elements in Apigee Edge accept different inputs.


Q 2. Whats the best practice for JWT Validation or how depth our validation of JWT need to be ?:

Do the public key validation and Algorithm validation is sufficient or Issuance and other customer parameter of JWT Token need to be validated by JWTValidation Policy ?

It sounds like you are asking for advice on validating JWTs. How you validate a JWT is up to you. The VerifyJWT policy requires you to specify an algorithm and a public key (of some sort); with that, the policy verifies the *signature* on the token, to insure that the presented signature can be verified with the key material you provide. In fact verifying the signature is the very first thing that the VerifyJWT policy does, after checking the basic format of the JWT (is it structured correctly?)

If the policy signature is valid, then you can be assured that all of the claims are bonafide. They have not been modified since the issuer of the JWT created the JWT.

The next thing the VerifyJWT policy does is check the validity times. There are two important claims: nbf and exp , indicating the not-before and expiry times for the token. The VerifyJWT policy will check that "right now" falls between those times, if they exist. If "now" is before "not before" or if "now" falls after the expiry, then the VerifyJWT policy will throw a fault: the token is not valid.

OK with a valid signature, and valid times, you can trust the claims. The next thing you have to consider is, which claims in the JWT are important?

And the answer there is, "it depends." Let me provide some additional commentary on various claims.

  • issuer - The issuer is a string claim that identifies the party that issued the JWT. Often this is a bit of redundant information. Remember the first step that the VerifyJWT performs is to verify the signature, and the policy does that using a public key of some sort. That public key often implicitly identifies the issuer, which means validating the issuer is redundant. BUT, it's also not harmful. It wouldn't take very long, and it might be helpful in your VerifyJWT policy to insert an <Issuer> element to communicate to future readers of the policy what you expect the issuer to be, explicitly.
  • audience - With an <Audience> element you can check the intended audience or receiver of the JWT.
  • subject - often important for you to check but not always.
  • any additional claims - you can check these with the AdditionalClaims element.

With all of these claims, depending on your use case, you may want to do additional validation. It's absolutely up to you.

In some cases the value in the token is important, and is used later in the proxy flow, but it's not necessary for the VerifyJWT policy to *validate* the value. For example there might be an account id in the JWT, and it's important that the account id be present, but you don't want the policy to validate a particular value.

To support the "use the extracted value later in the flow" use case, the VerifyJWT policy sets context variables that hold the values that it extracts from the valid JWT. For example, for a custom claim named "roles", the VerifyJWT policy will set a context variable named "jwt.POLICYNAME.claim.roles". And your later policies or Condition elements can examine that variable and do different things with it,