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?
Solved! Go to Solution.
Thanks @dchiesa1 @kurtkanaskie . Here are the additional details.
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 .
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?
@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:
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:
Thanks @dchiesa1 @kurtkanaskie . Here are the additional details.
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 .
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?
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!
This comes to mind:
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"
}
}
}