OAuth validation error for incorrect Content-Type

spsec · 10-12-2021 09:57 AM

A client encountered an interesting error scenario. They recently got a 401 from an ouath validation failure, but the message was:

oauthV2.Oauth-ValidateToken.fault.cause	UrlDecoding of the form parameters from the request message failed. The form parameters needs to be url encoded
oauthV2.Oauth-ValidateToken.fault.name	steps.oauth.v2.InvalidRequest

Which, indeed they sent Content-Type of "application/x-www-form-urlencoded" with a JSON payload. This particular operation does expect JSON, but I was surprised to find this error coming from the oauth v2 policy. The client did send the oauth token in the Authorization header. Of course, we're having them re-try with the correct content type, but I was just curious about this situation.

dchiesa1

I agree, that seems weird. That error seems surprising. Can you show me the policy configuration for Oauth-ValidateToken? I suppose it's pretty simple. But please send it to me?

spsec

Here it is (scope removed). I'll admit that there's some elements in here that are superfluous at the least. It would be curious if they were part of the cause, though. The policy has historically worked as expected.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="Oauth-ValidateToken">
    <DisplayName>Oauth-ValidateToken</DisplayName>
    <FaultRules/>
    <Properties/>
    <Attributes/>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Scope>(ourscope)</Scope> 
    <Tokens/>
</OAuthV2>

dchiesa1

Thanks. I'll take a look and revert here.

EDIT. I just tried this and I don't see the behavior you're seeing. I did not try it with the "superfluous" properties in the policy. I don't think that should matter, but in any case I didn't test it that way. If through your testing you find that the presence of those empty or unused configuration elements is in fact related to the problem you're reporting, then you have your solution.

Here's what I tested.

A simple "loopback" API proxy that does nothing except, VerifyAccessToken, and assign a message in response. The VerifyAccessToken looks like this:

<OAuthV2 name='OAuthV2-Verify-Access-Token'>
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

I tested that with 4 POST requests. Using combinations of Content-Type= {application/json, application/x-www-form-urlencoded} and combinations of valid JSON or form payloads. In no case did I see an error. The combination in which you reported an error was, passing Content-Type of "application/x-www-form-urlencoded" with a JSON payload. I saw no error in that case.

the results:

$ curl -i -H "Authorization: Bearer $TOKEN" https://$ORG-$ENV.apigee.net/validate-token-with-ctype-mismatch/t1 -d foo=bar -H "content-type: application/json"
HTTP/1.1 200 OK
Date: Thu, 14 Oct 2021 18:54:24 GMT
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
APIProxy: validate-token-with-ctype-mismatch r1

{
    "status" : "ok"
}

$ curl -i -H "Authorization: Bearer $TOKEN" https://$ORG-$ENV.apigee.net/validate-token-with-ctype-mismatch/t1 -d foo=bar -H "content-type: application/x-www-form-urlencoded"
HTTP/1.1 200 OK
Date: Thu, 14 Oct 2021 18:54:40 GMT
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
APIProxy: validate-token-with-ctype-mismatch r1

{
    "status" : "ok"
}

$ curl -i -H "Authorization: Bearer $TOKEN" https://$ORG-$ENV.apigee.net/validate-token-with-ctype-mismatch/t1 -d '{"foo":"bar"}' -H "content-type: application/x-www-form-urlencoded"
HTTP/1.1 200 OK
Date: Thu, 14 Oct 2021 18:54:55 GMT
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
APIProxy: validate-token-with-ctype-mismatch r1

{
    "status" : "ok"
}

curl -i -H "Authorization: Bearer $TOKEN" https://$ORG-$ENV.apigee.net/validate-token-with-ctype-mismatch/t1 -d '{"foo":"bar","bang":"baz"}' -H "content-type: application/json" 
HTTP/1.1 200 OK
Date: Thu, 14 Oct 2021 19:02:35 GMT
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
APIProxy: validate-token-with-ctype-mismatch r1

{
    "status" : "ok"
}

With a valid token, all combinations of payload and content-type header allow the "VerifyAccessToken to succeed. With an invalid token, the policy throws a fault. This all seems to be in accordance with expected behavior.

I have attached my proxy here.

If you can reproduce the problem, please provide specific instructions and an example API proxy.

spsec

Sorry, I left out an important bit of information. The requests that were failing did have illegal/un-encoded characters for "application/x-www-form-urlencoded" but were legitimate for application/json. I believe the offender was '%'. So, they created valid json, sent it with the wrong content-type, and then the oauth policy threw an error. The request was definitely bad, I am just surprised that the oauth step is the one which fails. In my example, I'm able to toggle the error by changing the Content-Type header. I'm going to try replicating using your proxy.

spsec

Still curious as to why the oauth policy was having an issue with the invalid/unencoded characters. Perhaps because of support for oauth tokens as form parameters?