OAuthV2 vs. JWTVerify for third-party OAuth tokens in Apigee X

[marcpatterson]

Hello.  I am using a third-party OAuth server to generate JWT access tokens, and following the pattern described in Apigee X's guide here.  

Looking for advantages/drawbacks of using the VerifyJWT policy to validate a JWT access token compared to the OAuthV2.VerifyAccessToken. 

• It appears that VerifyJWT is a lightweight mechanism to validate JWT-specific items such as digital signature and token expiry but requires additional code / considerations for validating specific JWT claims or OAuth scopes (using the pattern described in GC forum here).
  
  
• OAuthV2 contains simple validation capabilities for scopes, so it feels like this policy is a better fit for enhanced OAuth scope and flow validation (client credentials vs. password vs. authorization code grant types), or essentially OAuth capabilities beyond basic JWT token validation.
  
  
• Interested in how the new OAuthv2.VerifyJWTAccessToken operation factors into the decision, if at all.

Feedback is appreciated.  Thank you.

[Former Community Member]

The new OAuth2.VerifyJWTAccessToken (and other such operations) conforms to the RFC 9068. You can think of the VerifyJWT policy (as well as generate and decode policies) as general purpose policies that allow you work with JWT as described in RFC 7519. The OAuth policy (VerifyJWTAccessToken) is a special case. This is the case where Apigee generates JWT formatted access tokens and both Apigee and non-Apigee gateways can verify it.. The way the claims are named, how the token is used etc. are all determined by RFC 9068.

[dchiesa1]

Yes.

It appears that VerifyJWT is a lightweight mechanism to validate JWT-specific items

I would describe it as, VerifyJWT is a way to validate signed or encrypted JWT, regardless of the issuer. You can configure the policy to verify specific claims, either "standard" ones or non-standard ones. The one thing that you cannot do easily today with the VerifyJWT policy is verify a pattern match, or partial match of a claim against a target value. You cannot, within the policy, implement a check like "does the scope claim include the string ruaq?" THAT requires an external check. Which I think might be the topic of that community post you linked to. It's easy to implement in Apigee , but it does require a second step after VerifyJWT. 

OAuthV2 contains simple validation capabilities for scopes, so it feels like this policy is a better fit for enhanced OAuth scope and flow validation

The JWT standard, as far as I know, does not specify a claim for "scope" or "scopes" on a JWT. The first time that claim was mentioned, as far as I know, was RFC 9068 in section 2.2.3. The VerifyJWT hasn't been updated since the publication of that IETF RFC.

I expect in the future that the VerifyJWT policy will be enhanced to verify things like "does the scope string contain X"?

[marcpatterson · Accepted solution]

Thank you @Former Community Member and @dchiesa1 for your reply. 

Clarification on the intended RFC(s) is helpful.  In summary, we will use OAuthv2 for validating access tokens and inspecting claims (scopes) in the OAuth context.  We will consider VerifyJWT as a generic JWT validator "regardless of issuer" as @dchiesa1 stated.