JWT validation with JWT creator

[abiram8]

Hi,

JWT Validator (inbuild Apigee Policy) is capable of validating the JWT (which was generated by OKTA/PING/Gigya)

Is there any reason apigee will to go to the JWT creator (like OKTA/PING/Gigya) for validation as well?

Sender in this case is wither public /internal system/browser.

[dchiesa1 · Accepted solution]

Is there any reason apigee will to go to the JWT creator (like OKTA/PING/Gigya) for validation as well?

Generally with signed JWT, there is no need for the verifier of a JWT to connect to the issuer* of the JWT to verify and validate a token (JWT = JSON Web Token).

The general rule, that the verifier need not connect to the issuer in order to complete the verification, applies in this specific case you are asking about, in which Apigee is the verifier, and (Okta/Ping/Gigya) is the issuer.

*There is one exception to the statement that the verifier need not connect to the issuer: the verifier needs the public key of the issuer, in order to verify the signature that the issuer has created. In all of the cases you described, as far as I know, the issuer uses Public/Private key cryptography in order to produce the signature, and I believe they all use RSA keys. Typically the issuer publishes the public keys for its signatures at a well-known endpoint that is accessible from HTTP, and it publishes the keys in JWK format. An example from Google is here. Every Okta tenant has its own JWKS endpoint, and I believe the same is true for Ping and Gigya.

The verifier needs to retrieve the public keys from that endpoint. This is a simple HTTP GET. And then the verifier should retain (cache) them, so that as it verifies JWT that have been issued by the issuer, it can get the keys from memory. Retrieve the public keys once, and use them many times for validating JWT.

In the process of validating the JWT, the verifier/validator first checks the algorithm and that the signature is valid according to the public key. Then it checks the validity times (expiry and not-before), and perhaps can check other claims in the token, such as the issuer (iss) or audience (aud) claims, in order to determine that the JWT is valid and should be trusted.

After deciding that the JWT is trusted, the verifying application can then take decisions based on the claims within the JWT - like subject (sub), or any other non-standard claims.

This is the pattern that the VerifyJWT policy follows in Apigee.

This model, in which the verifier of a JWT need not connect to the issuer of the JWT, in order to verify the JWT, is one of the key attributes of the use of signed JWT for tokens.