Query regarding JWT Verify Policy Runtime Error

[sidd-harth]

Hi guys, as per Verify JWT Policy Runtime errors , the policy is capable of throwing different errors like JwtIssuerMismatch, JwtAudienceMismatch etc.,

For Token Expired, I am getting the correct error, "errorcode": "steps.jwt.TokenExpired"

But when I try to verify a JWT with an incorrect/mismatched Audience or Subject or any other claim. I get a generic InvalidClaim error. It doesn't give me the specific claim name.

{
    "fault": {
        "faultstring": "Invalid Claim: policy(Verify-JWT-1)",
        "detail": {
            "errorcode": "steps.jwt.InvalidClaim"
        }
    }
}

I am using a Nodejs based proxy to generate JWT token which has HS256 algorithm, nbf, exp, aud, iss claims.

I am using nbf claim with 30secs time(after the token is minted) before which the JWT must not be accepted for processing. There is no runtime error mentioned for nbf claim so I assume the policy uses generic Invalid Claim error.

Token Generation can be done using below url,

http://onlineman477-eval-test.apigee.net/jwt_test/generateToken?apikey=zuhz7Gt2ojHamB64x5DMb1VZRoV0T...

Above mentioned apikey itself is the JWT Secret in my sample proxy.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyJWT async="false" continueOnError="false" enabled="true" name="Verify-JWT-1">
    <DisplayName>Verify JWT-1</DisplayName>
    <Algorithm>HS256</Algorithm>
    <SecretKey>
        <Value ref="private.privateKey"/>
    </SecretKey>
    <Issuer>siddharth.cfapps.io</Issuer>
    <Audience>API Developers</Audience>
    <AdditionalClaims>
        <Claim name="personal_id" type="string">sid</Claim>
    </AdditionalClaims>
</VerifyJWT>

PFA Proxy validateexternaljwtokens-rev3-2018-08-15.zip

Is it the expected behavior or can anyone else reproduce this?

@Dino-at-Google

[dchiesa1 · Accepted solution]

I'll need to look into the Runtime errors documentation.

The VerifyJWT policy issues a generic fault for verification failure when an invalid claim is presented.

The specific error can be examined in the .error context variable. See below for my trace capture:

The reason we want Apigee Edge to issue a generic fault is that we want to minimize the amount of information the API proxy will release to unauthenticated clients, in the case of a JWT validation faillure. We don't want to automatically give hints "oh, the issuer is incorrect", "now the subject is incorrect". This allows an attacker to use a brute force, continuous feedback effort to try to find a good JWT.

So the fault is generic.

if you want your API proxy to emit something more specific, you can do that by referencing the .error context variable.

[sidd-harth]

Now the generic error makes sense. Thanks, Dino for the explanation.

Yeah, I was able to see error context in Trace, but I wondered why it was giving a generic error as a response when the doc had a wide range of errors for various claims.

Even the nbf claim error can be seen in the trace.

Maybe your point needs to be added to the docs. ++ @Floyd Jones

For the sake of best practice, what do you suggest when it comes to Error Handling(Fault Rules), should we only use a generic InvalidClaim(for all claim errors besides nbf) to avoid giving hints which might lead to brute force attacks?

[dchiesa1]

Floyd, if you read this, also see b/112705614 .

Siddharth, we are considering modifying the runtime to expose the symbolic error names as well, and not just the human-readable error messages.

And yes, you need to take care to expose minimal information to unauthenticated clients. You may wish to log error classes with a MessageLogger. But not all internal information (like your JWT is signed with the wrong algorithm, your JWT has the wrong issuer claim) needs to be returned to the client.

[jonesfloyd]

Thanks for the ping, guys. @Dino, I've filed b/112715435 for the doc clarification.