Getting an "Invalid Scope" for OAuth 2.0 after upl...

Char-K · 10-02-2023 12:45 AM

Hello,

I need help with regards the apigee oauth 2.0 scope. I added the scope in API Products with this format: "urn:sample:api" but I am getting below error response:

{
    "fault": {
        "faultstring": "Required scope(s): [urn:sample:api]",
        "detail": {
            "errorcode": "steps.oauth.v2.InsufficientScope"
        }
    }
}

Instead of this sample response:

{
    "error_code": "403",
    "error_summary": "forbidden",
    "error_description": "InsufficientScope"
}

Thank you for any assistance/help on this.

dchiesa1

Hi

It looks like the FaultRule you have configured is not executing. I say this because the error response you are observing is the default error issued by Apigee, when there is insufficient scope. I think you are attempting to override that error message with your FaultRule. It does not appear to be working.

The most common reason for this is that you have OTHER fault rules, and one of those other rules is executing. That would prevent the first faultrule from executing. There is one weird trick with Apigee fault rules: they are evaluated bottom to top. I am not sure why it was designed to work this way, but it does work this way. So if you have 3 faultrules and the rule that appears third in your configuration executes, the other rules are not evaluated. And, notice that you can attach a condition to a rule, or to a step within a rule. Suppose that you don't attach a condition to a faultrule. It will always execute. Even if you have 3 steps within the rule, each with conditions, and none of those conditions evaluate to true, therefore none of the steps execute, the faultrule itself will have been executed. Therefore none of the other faultrules will execute. This is by design. And it is explained in the "fault handling" section of the Apigee documentation.

BTW: If you run your API proxy through Apigeelint, it will flag a "fault rule with no condition" as a problem, and will tell you to fix it. If you have a FaultRule with no Condition, it should always be at the very top of the list of FaultRules.

If that isn't the problem, then....If I were you , I would use the Trace/Debug session facility in Apigee to see if your FaultRules are executing. And if not, you may proceed to determining why not. Maybe the FaultRules are not configured in the proper place in the PrroxyEndpoint. Maybe some other problem.

Finally - The rule you showed... is not the problem! I just tried your FaultRule, and it works just fine if there is no other fault rule. The fact that you showed only a partial configuration of your proxy, not including the "close FaultRules" element, tells me you might have an additional FaultRule lurking in there, with no Condition.

Char-K

Hello Dino,

Thanks for responding!

dchiesa1

Well, no that does not clarify for me. There is a lot going on there that I don't understand. and unfortunately I don't believe I will be able to understand.

But I can offer some general observations.

You do not need request.verb != "OPTIONS" in those Conditions in the preflow. The CORS policy will "short circuit" the request and will send back a response, in the case of an OPTIONS request. You probably want to omit them.
The 500 error response for a schema problem... would that be a schema on the REQUEST? If so, 500 is wrong. It should be 400. Only if the server itself is responding with something that violates a schema, should the error be 500. A 500 status is "The API is experiencing an error". It's intended to communicate that there is a bug on the server side. In the case of an Apigee-managed API, a 500 indicates an error either in Apigee, or in the upstream. a 400 indicates a problem with the request. Eg, with 400 Apigee can say, "Client, You sent me a broken message, the payload does not conform to the required schema".
It seems like you have lots and lots of steps in the logic to handle faults. For example the fault that the content-type or accept header is not quite right, has 9 steps. !! Why so many? Why not just ... emit an error message? "415 unsupported media type" done. but you don't need to answer that question; it's just something for you to think about. My general philosophy is that fault handling should be pretty lean. Otherwise you run into the case in which the faulthandling logic ...throws faults. Reading KVMs and executing large JS in faultRules? Why so much?
Why would you use AssignMessage-406NotAcceptableException in your FaultRule? you already have a RaiseFault for 406, attached to the preflow. The RaiseFault allows you to specify a response message. You should't need to re-assign that message in a FaultRule.
one small suggestion. This
```
    <AssignVariable>
        <Name>req.sample</Name>
        <Template>{req.sample}</Template>
    </AssignVariable>
```
..doesn't do anything. If the req.sample variable holds "foo" before that AssignVariable, it will hold "foo" afterwards too. I hope you can see why.
Last, if you are still experiencing problems, I will repeat what I said above: I think you should radically simplify this proxy, remove everything you can. Then, build a few tests, and adjust things so the tests pass. and then add a new fault rule (a simple one), and tests to exercise it, and adjust things so the tests pass. Gradually and iteratively add configuration and tests, until it satisfies your requirements. Don't start from the large configuration with 9 steps in the fault rule.

Good luck sorting it all out!

Getting an "Invalid Scope" for OAuth 2.0 after uploading the same proxy bundle