support for oauth password grant type with no predefined scope in api production or app - apigeex

[raghunathapalle]

Hi  @dchiesa1 @kurtkanaskie  We are trying to migrate from TIBCO Mashery JSON RPC calls with oauth password grant type to ApigeeX for oauth token generation & validation. Currently TIBCO Mashery doesnt have a predefined list of scopes & doesnt validate the scope during token validation.When we migrate the flow to ApigeeX, ApigeeX need the scope defined in the product/app & we are seeing failure in token validation call saying 'secure token is invalid' if we don’t predefine the scope in apigeex product/app. Is there a way to solve this?

[dchiesa1]

---

@raghunathapalle wrote:

trying to migrate from TIBCO Mashery JSON RPC calls

---

Wow!  A blast form the past!  (??)

---

@raghunathapalle wrote:

ApigeeX need the scope defined in the product/app & we are seeing failure in token validation call saying 'secure token is invalid' if we don’t predefine the scope in apigeex product/app. Is there a way to solve this?

---

I don't know if you can solve it. The way it works: in OAuthV2/VerifyAccessToken, if you include a Scope element in the step configuration, then the Apigee runtime will verify the token only if the specified scope is present on the token.  Even if the token is otherwise valid (issued by Apigee, not expired, good for the currently executing request, not revoked, etc), Apigee will still reject it if the required scope is not present. I think this is what people want to happen, in general.  If you don't want this behavior, just omit the Scope parameter in the VerifyAccessToken policy. 

ok so how does one obtain a token that has a scope?  For that you need to do several things:

• specify one or more scope strings on the API Product at the time you define the API product. (Not on the app!)
• at the time you issue the token, via OAuthV2/GenerateAccessToken, specify in the Scope element, a variable that describes which scope or scopes you want on the token.  (Let me emphasize that, because this was confusing to me, initially. The usage of the Scope element in the OAuthV2 policy is different , depending on whether the Operation is GenerateAccessToken or VerifyAccessToken.  For GenerateAccessToken, the Scope element specifies a variable, containing the actual scope that is being requested. For VerifyAccessToken, the Scope element specifies an actual Scope string.) 

This is explained clearly, and in good detail, on this page of Apigee documentation, entitled "Working with Scopes". 

ok, it sounds like what you want to do is issue a token with a Scope, but you ... don't want to specify the possible set of scopes on the API Product, prior to that.  I can't imagine why you'd want to do that, but if my understanding of what you want is correct, then the answer is no, you cannot do that in Apigee. 

Maybe take a step back and explain to us: 

• why are you introducing token scopes now, as you migrate from Mashery into Apigee?  What's the goal with this? 
• Why do you not wish to configure the possible set of scopes on the API product, yet still wish to verify a Scope on a token issued for that product?

[raghunathapalle · Accepted solution]

Thanks @dchiesa1 @kurtkanaskie . Here are the additional details.

• why are you introducing token scopes now, as you migrate from Mashery into Apigee?  What's the goal with this? 

Raghu - Looks like 10 years ago when we implemented API Management using TIBCO Mashery, we use scope to send the secure token (encrypted with timestamp & secret key )generated from our IDP & Mashery was generating just access tokens & refresh tokens to validate the token for the resource endpoint. Once token verification is complete Mashery used to generate the http header with scope which can be validated by backend . Backend does the decryption of the secure token coming in scope header. In this use case ,Mashery never does the scope validation like Apigee does .

• Why do you not wish to configure the possible set of scopes on the API product, yet still wish to verify a Scope on a token issued for that product?

Raghu - So we tried to use custom Attribute in the token generation & retrieve the same attribute after token verification in resource endpoint & generate the http header with scope needed by backend to exactly lift & shift the functionality from Mashery to Apigee. This works for us now. Do you see any flaw with this approach? 

[dchiesa1]

No, I see no flaw in that approach. That's a reasonable thing to do, and it's the kind of thing the custom attribute feature was designed for. 

I'm glad you got it sorted out!

[kurtkanaskie]

This comes to mind:

• Patient: Doctor it hurts when I do this.
• Doctor: Well then don't do it.

As Dino said, you don't have to use Scopes. 

Even if you do use scopes you can useVerifyAccessToken without a Scope element to validate the token.

If you do use scopes and you include a scope value on VerifyAccessToken, you'll get this error on a scope mismatch:

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