Should I Verify or Decode a JWT? both? In which order?

[pratysin]

Hi Team,

I have a JWT token which i want to verify and decode the token. In order to decide, i was wondering which API Proxy i can use first i.e. either Verify JWT Token or Decode JWT Token.

Thanks

Pratyush

[dchiesa1]

First, let's clarify the nomenclature:

• The VerifyJWT and DecodeJWT things are POLICIES. There are 35+ biult-in policies in Apigee and these are just two of them.
• Proxies are the things which hold a configuration of various policies, and the order in which they should execute, and any conditions that apply to their execution.

If you want to verify and decode, then use VerifyJWT.

If you want to decode a JWT without verification, use DecodeJWT.

Take care when Decoding a JWT without verification. Here's why: The claims in a JWT are signed, which means any system that receives the JWT can verify the signature, and after successful verification, can trust that the claims are bona-fide, and have been asserted by the signing party (in other words, the holder of the signing key). If a system (or app) that receives a JWT merely decodes the JWT to obtain the claims, the receiving system has not verified that the claims in the JWT are bona-fide. Therefore that system must treat those claims as untrusted. There are good reasons for decoding a JWT without verifying the claims, which is why we have a policy to allow it! But you need to take care.

Why would you build a proxy that would decode a JWT but NOT verify its claims? Normally, you wouldn't. In most cases it's NOT decode-and-dont-verify; it's decode-and-then-later-verify. Some examples of when this might be a good idea:

1. Your logic requires that you validate the claims in a JWT in other ways... for example your app requires that the JWT itself have a maximum lifetime of 300 seconds or less. Or your logic requires that the "aud" claim in a JWT be a known (perhaps fixed) string. In that case you might want to decode the JWT, check thoe claims, and then if the claims look good, verify that the claims have been properly signed, and THEN proceed with handling the API request.
2. Your logic requires that you use some of the claims in the JWT to lookup the key that must be used to verify the JWT. A really common scenario is an HS256-signed JWT, which uses the client_id as the "sub" and the client_secret as the signing key. The API Proxy won't be able to retrieve the client_secret needed to verify the signature until it decodes the JWT. Then it has the client_id and the proxy can use VerfyAPIKey to validate the client_id and implicitly retrieve the client_secret. THEN, the proxy can use VerifyJWT to verify the signature on the JWT, and after that the proxy can trust all of the claims in the JWT.

Some implications and rules to follow:

• In general, it's not a good idea to use the DecodeJWT policy without a "nearby" subsequent VerifyJWT policy. If you have a proxy that does that, you're probably making a mistake with security ramifications.
• If you have a VerifyJWT policy followed by a DecodeJWT policy, you're probably making a mistake without security ramifications. It does no harm except that your proxy is performing redundant work, and it will be less efficient than it could be.

If any of this is not clear, Apigee experts or experts that work for partners of Apigee can help coach you through these choices. Contact us, either directly through your account rep (if you know that person), or through the web form, and we can have a conversation.

[#3]

It seems you have created two separate proxies for verify and decode of JWT token. I would suggest not to go for separate proxies if you don't have the requirement of separate requirements. I would suggest using both in the same proxy. It is a good practice to verify first and then decode.